On Sun, Jan 17, 2010 at 03:45:06PM -0500, Daniel Richard G. wrote: > Isaac Dupree wrote: > > I accidentally have an out-of-order partition table and I was > > surprised that such a thing is possible (vs. that everything gets > > automatically numbered in order). Nevertheless, it is a useful > > feature, though not obvious how to control with 'gparted' and the > > like. "extended partitions" probably add a bit of complication too. > > Yes, I used fdisk(8) to get the effect, but with most "user-friendly" > partitioning tools I'd have been SOL. I'm thinking about the implications for > something like the Ubuntu installer/partitioner, which has to be dead simple > for the user, and yet producing an out-of-order table would be a helpful > measure of interoperability with Windows systems.
The Ubuntu installer's partitioner (essentially due to how libparted works, so I expect any libparted-based partitioner is similar) will produce out-of-order partition tables when it's convenient for itself to do so: it avoids renumbering partitions since that tends to break existing operating systems relying on those partitions, so when you resize a partition to make some space and then create new partitions in that space you'll typically get an out-of-order partition table. Unfortunately, I rather suspect that the very problem being addressed there means that we won't be able to implement your idea automatically. Artificially renumbering the partitions of an existing operating system while installing Ubuntu would be likely to break that operating system in many cases (as a convenient simple example, consider a Unix-based system referring to that partition in /etc/fstab using traditional device names rather than UUIDs), and we have no way I can imagine to tell whether that's going to be the case or not. There are many different possible BIOS limitations (see http://tldp.org/HOWTO/Large-Disk-HOWTO-4.html) and I doubt that we can sensibly warn about all of them or even necessarily evaluate accurately which is the most likely. GRUB might be able to avoid the problem you describe by using ata.mod, provided that its core.img is embedded just before the first partition, as recommended, rather than being installed in a partition boot record past the BIOS barrier. For all kinds of reasons, I would love to have a way to detect these kinds of BIOS limitation in software, but I've never found a sensible way to do it. The best suggestion I've heard is to read the BIOS software version using DMI or similar and then check it against some kind of giant database, but I don't have the resources (time or expertise, really) to build up such a database, and I don't even know whether BIOS version numbering is reliable enough to make it practical. -- Colin Watson [cjwat...@ubuntu.com] _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel