[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

GRUB device numbers/names, use of device.map (Re: migrating Debian GNU/Linux Etch to second SATA drive)

Am 2008-05-10 um 07:01 schrieb Paul Csanyi:

hh.eu@gmx.de writes:

By the way, if you have a floppy drive, you can install GRUB on a
floppy too, then you have a GRUB emergency disk which lets you
perform operation such as those you described (in the GRUB shell)
(for cases of drive failure etc.).


That shall I to do, or maybe there is an alternative option, say to
install GRUB on the USB stick as emergency disk?

I haven't done that, but it should also work.

Make sure you test if you can actually boot from your USB stick or not because
not all machines can boot from USB devices. E.g., I have a computer that
should be able to do it according to the manual and all the settings in the BIOS, but after hours of trying I still couldn't get it to work, it's a buggy BIOS. Also, if it works on one of your machines, it may not work on another or
computer of a friend who you are trying to help.

If you are frequently using the USB stick, you might occasionally format it,
erase it etc., so be careful not to destroy your GRUB install on it.

Then, I guess, you have to be careful with the GRUB drive numbers (hd0, ...) when you use the USB stick. E.g., depending on whether or not the USB stick is plugegd in or possibly even which controller it is plugged into, the numbers of all drives may be different. Depending on the BIOS, the USB stick might be considered a floppy drive, so it might be fd1 instead of hd1, for example. So you should be very careful when you try to reinstall GRUB, to ensure you are
not (for example) overwriting the MBR on a Windows disk.

Generally, GRUB uses some sort of *guessing* to assign the drive numbers, so
one always has to be careful.[1]

(All of the above of course also applies to the case where you use a floppy.
But then you will at least usually know that fd0 is your regular floppy

The GRUB shell offers the "find" command. You can use it to find a certain file you know exists on a particular drive, which will help you find out which
device number GRUB uses for that disk.

Another tip is to type something like "root (" + tab, it will give you a list of possible devices, then complete the name of one device and use tab again, GRUB should then tell you which file system is on that disk which might also
help you.

Then there is a file named /boot/grub/device.map where one can define which device should have which number, but the use of this file is quite confusing and poorly documented, and it took me many tries to understand. (The GRUB manual and all sorts of search results couldn't help me clearly.) Summary:

(1) If GRUB is started from within Debian:
* If started with the command "grub", the file device.map is ignored. GRUB
  assigns device names (hd0 etc.) based on *guesses* it makes.[1]
* If started with the command "grub --device-map=device.map" and the file
  device.map exists, the file device.map is parsed.
* If started with the command "grub --device-map=device.map" and the file device.map does not exist, GRUB *guesses* the device names [1] and stores
  the result of the guessing in the file device.map.

(2) If GRUB is started directly from the BIOS (GRUB shell):
* The file device.map is ignored, the device names are derived from GRUB's

Note that (2) is also the situation you have when you boot your system
normally. In other words: Making changes to device.map does not influence device numbers actually used by GRUB when booting. (That's why I don't use
that file, I personally find no use for it.)


[1] This guessing can, of course, never be really consistent and leads to all sorts of confusing situations, e.g. different device numbers depending on
whether GRUB is started from the BIOS of from within Debian or different
numbers after changing cables in the computer. It is one of the fundamental logical flaws in the design of GRUB and one of the reasons GRUB 0.97 is not developed further. (Development effort goes to GRUB 2, currently at version 1.9something, which has been in the works for years and is still not ready for
release and is not documented yet, so for most people is not a viable

Reply to: