On Tue, 2005-03-22 at 14:44 +0100, Molle Bestefich wrote:
> Dennis McMurchy wrote:
> > Thanks a million. That got me on the right track, finally.
> >
> > It didn't solve the problem right away, though, because it turned out
> > that the 'device.map' file that was being generated was wrong in a way that
> > wasn't immediately obvious to me. It was giving me this (even though
> > the BIOS is set to boot from SCSI before IDE):
> > [snip]
> > When I finally changed the 'device.map' manually to look like this (and
> > updated 'grub.conf' accordingly, of course) everything worked just fine:
> > [snip]
> > I don't know if this really qualifies as a bug or not, but I'm just
> > delighted to have this working finally.
>
> This bit, together with HighPoint RAID corruption, has been keeping me
> away from GRUB for years.
>
> As far as I understand, it's a wild guessing game that GRUB does,
> which IMHO is just crazy.
>
> Then again, I don't know the guessing algorithm.
> Can anybody elaborate? Jason?
You *can't* solve this problem on x86. There is no reliable way to ask
the bios if it can address a disk, or what ID would have.
>From the OSes point of view, you need to know some identifier that's
meaningful to the OS, and which bios id (0x80, 0x81, etc) is assigned to
that device. On x86, since bios doesn't provide a "device tree" like
e.g. Open Firmware does, the storage device's location is essentially a
tuple of the card's pci bus id, which of the card's buses the device is
on, and the device's number on that bus. That is, for /dev/hda in my
laptop, it's [ide 0,bus 0,device 0].
The best attempt at solving this is EDD, which allows the OS to probe
each bios drive and returns exactly that tuple. Unfortunately, very few
vendors actually implement EDD in a way that the data even conforms to
the specification, and of those that do, the overwhelming majority just
provide bad data. So you can't rely on EDD at all.
The reason they don't get this right is that x86 bios isn't designed to
actually address the disks directly in the first place. It knows that
there's a card which provided an extension ROM. The ROM is the only
part that knows anything about how it maps IDs to storage devices -- in
some cases, such as hardware RAID, the device presented to bios doesn't
necessarily even exit.
I'm sketchy on the details, but I believe the algorithm bioses tend to
use is something along the lines of:
1) bios goes and searches for pci cards
2) for each card that provides an expansion ROM, bios maps that ROM to
memory, and executes some code provided by the ROM. That code adds
entries into the bios's list of what devices it can boot. These
entries essentially are a vector of [read,write] functions.
3) iterate the devices (maybe in order, maybe in some user-defined
order, we don't really care) looking for valid boot blocks.
So the BIOS itself doesn't have any more information. All it knows is
that card 2 put entry 0x80 in the list, and when the first sector is
read from 0x80, a valid boot record is returned. That's where it hands
off to the OS, which is left in just as perplexed of a state.
--
Peter
_______________________________________________
Bug-grub mailing list
Bug-grub@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-grub
