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.).
-Moritz
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
drive.)
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
guessing.[1]
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.)
-Moritz
[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
alternative.)
Reply to: