Re: "grub" command works, but GRUB boot loader hangs

[Ben Liblit]

I wrote:
> I have no such file [/boot/grub/menu.lst].

Wilhelm Wienemann wrote:
> AFAIK you need such file to use GRUB as a bootloader.

That cannot be true.  One can simply concatenate stage1 and stage2
onto a floppy disk and use that as a boot floppy.  No "menu.lst" is
required.

> From where should GRUB it know which harddisks are mapped if you
> aren't using a 'menu.lst' file?

GRUB will name the first hard drive it sees (hd0), the second one
(hd1), and so on.  I don't see where a "menu.lst" file must come into
the picture.

> >       /dev/sda  <=>  (hd1)
> >       /dev/sdb  <=>  (hd2)
> >       /dev/hdc  <=>  (hd0)
> 
> Is that the BIOS order of booting or what should it be?

That is the Linux <=> GRUB correspondence that I can determine from
running the "grub" command under Linux.  My BIOS boot order is to look
first at my floopy drive and then at "C:", which ends up being
/dev/sda thanks to some help from my SCSI controller's BIOS.

> What's the output of 'cat /boot/grub/device.map'?

I have no such file.  Nor is any such file required when all I'm
trying to do is get the geometry of a GRUB device.

> For me it's unclear in which order you are mapping the harddisks for
> GRUB.

*I* am not mapping anything.  GRUB is selecting mappings
automatically.  When run as a command under Linux, GRUB maps /dev/sda
to (hd1), /dev/sdb to (hd2), and /dev/hdc to (hd0).  When run as a
boot loader, GRUB appears to map /dev/sda to (hd0), /dev/sdb to (hd1),
and does not present any device corresponding to my IDE drive.

But that's all irrelevant.  The order doesn't matter.  I couldn't care
less what the order is.  A command like "geometry (hd0)" should
produce some kind of meaningful output.  I don't care if (hd0) is my
first SCSI disk, my second SCSI disk, or my IDE disk.  It doesn't
*matter*.  No matter which disk it is, "geometry (hd0)" should
describe its geometry.  But when GRUB is run as a boot loader,
commands like that just hang outright.