Comment 8 for bug 423448

In general, it is not possible to even discover the BIOS ordering from
Linux. This perhaps non-obvious constraint (beyond the control of GRUB)
makes all kinds of things rather difficult. I have banged my head
against this fruitlessly in the past, and have no intention of wasting
very much time on it again; it was, mostly, a blind alley. Dell have a
set of BIOS extensions called EDD which let you do a little better, and
it might be worth supporting those in GRUB's device.map code, but
they're only supported on a fraction of today's PC-class computers.

Furthermore, BIOS ordering is unstable (in particular, consider
removable drives), so we can't rely on it, convenient as it might be in
some scenarios. This is why we normally use UUIDs when booting operating
systems from GRUB, and in general try to avoid relying on BIOS ordering
at all. However, FreeDOS probably doesn't support this kind of scheme.
I'll endeavour to test FreeDOS in a multi-drive test system. I don't
think that it is directly related to the things I'm trying to discuss
with Felix here, although fixing those is probably a prerequisite for
making this work reliably.

Your comments about Image for Linux (not a product I'm familiar with)
are presumably simply due to them using a new kernel which enumerates
devices in a different order. I haven't taken this into account because,
while I'm sure it is a bug, it is not my problem; I'm afraid that this
is beyond my control and nothing to do with GRUB. No doubt the
application needs to improve how it displays disks.

I'd appreciate a *separate* bug report (on partman-base) about
displaying volume labels in the installer's partitioner. Let's try to
keep this bug report somewhat under control in terms of scope so that we
can fix it.