[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Trouble booting from a large USB hard drive

From: Colin Watson
Subject: Re: Trouble booting from a large USB hard drive
Date: Mon, 18 Jan 2010 00:07:16 +0000
User-agent: Mutt/1.5.18 (2008-05-17)

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 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                                       address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]