Re: Trouble booting from a large USB hard drive

[Colin Watson]

On Sun, Jan 17, 2010 at 08:54:42PM -0500, Daniel Richard G. wrote:
> Colin Watson wrote:
> > 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.

Unfortunately it seems that often even recent machines suffer from them.
The date doesn't appear to be a good guideline.

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

I believe, but am not sure, that ata.mod is not quite stable enough for
universal use yet.  If it were I imagine we'd be using it instead of
biosdisk.mod.

I don't believe there's room for both methods at once, but one or the
other should just about fit.

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

I just have no idea even how to assess what is reasonable to warn about
here, and am reluctant to make changes based on guesswork.  I also
really, *really* don't want to scare people into attempting to make
complicated and perhaps even risky partitioning changes when in fact
their BIOS would support their current layout just fine.  This is why
I've never done anything about this problem, although it and its friends
have been around for some time.

> 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'd much rather do this in manual partitioning.  Canned layout options
are highly contended and I want to reserve them only for the most
important and widespread options.

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

I'm not sure what's reasonable yet, but feel free to file a wishlist bug
on the partman-base package in Ubuntu for some kind of way to renumber
partitions.  If you referenced this thread, that would be good for when
we come back to this in the future (as I'm not sure I'll be able to
attend to this straight away).

Thanks,

-- 
Colin Watson                                       address@hidden