RE: Trouble booting from a large USB hard drive

[Daniel Richard G.]

Colin Watson wrote:
>
> 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.

I was just thinking of the narrow case of a new partition table, perhaps 
narrowed even further to USB drives (unless there's an advantage to the odd 
order with IDE/SATA/SCSI disks). If the user is only modifying an existing 
table, I agree that the numbering shouldn't be touched.

> 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.

Well, the most recent barrier (aside from the one at 2TiB that's just around 
the corner) of 137GB dates back to 2001... I suppose you could check the BIOS 
release date via DMI and warn about smaller limits if it's anywhere near that 
old. Are machines of this vintage even a worthwhile concern? I thought I'd 
read somewhere that not even overseas digital-divide charities will bother 
with such hardware.

> 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.

This isn't the norm? Was I wrong about there not being enough space before the 
first partition to store non-BIOS disk-reading routines? This wasn't the case 
with the Karmic install, so I presumed there wasn't a way to do it.

> 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.

And it's somewhat moot anyway, since disks can be moved between systems 
(though this is less likely with fixed disks, of course). I'm thinking the 
reasonable thing to do would be to show a warning if /boot is beyond 137GB (or 
maybe 33GB? 8.4GB?) on a USB disk unconditionally, and maybe on fixed disks if 
the BIOS is detected as being older than a certain date (much as how the 
kernel doesn't use ACPI if the BIOS predates 2000/2001).

Beyond that, having the partitioner support out-of-order numbering would be 
great, though I don't see an obvious way of doing it in the 
manual-partitioning dialog. It would be easier to support it as a canned 
layout option, perhaps available only for USB disks. But I also like to have a 
separate /home, and that means manual partitioning, so....

(I'll be happy to file a wishlist bug report against ubuntu-installer if we 
can figure what would be reasonable for it to do.)


--Daniel