Is device.map relevant at boot up time?

[stoat]

People often seem to think so in forum posts, and they sometimes edit it to try to get an operating system to boot. And even though some of those booting dilemmas were successfully resolved and editing the device.map file was involved, that alone is not what led to success whether the poster realized it or not. I believe the device.map file is not used by GRUB during booting. Ever. I concede that this is a matter of relatively small importance especially since correcting errors in the device.map file is a harmless thing to do in either case. But if not for booting, when is the device.map file relevant? What follows is my case against the title question, my conclusions about when device.map is used and the real role it plays in solving booting problems. If I am wrong about anything in this post and you can prove it, please do it now. I will be grateful. If you are irritated by trivia and minutiae, you should leave now.

IMPORTANT NOTE: Everything in this post relates to GRUB v0.97. There is a new generation of GRUB in development now with changes like adding a graphical interface, adding a rescue mode to save unbootable cases, dropping Stage 1.5, changes to partition numbering.

A forum poster by the name of adrian15 (the Super GRUB Disk guy?) at Nabble Forums claims that device.map is not involved in booting in three posts there. And in a fourth post where he recommends editing device.map, he instructs the poster to reinstall GRUB after that.

In a post by pxumsgdxpcvjm at linuxquestions.org, pxumsgdxpcvjm celebrates successful dual booting but puzzles over the inconsistencies in devices between device.map and the grub.conf in that working system.

The Legacy GRUB Page of Herman's Illustrated Dual Boot Site has a section on editing the device.map file that makes the point that GRUB must be re-installed after editing the device.map file. Not only that, but it matters how GRUB is re-installed for editing device.map to make any difference.

So much for forum posts. I also read other sources of information.

According to the GRUB manual...

The reason why the grub shell (my italics) gives you the device map file is that it cannot guess the map between BIOS drives and OS devices correctly in some environments. For example, if you exchange the boot sequence between IDE and SCSI in your BIOS, it gets the order wrong.

A SUSE Linux guide has a section on GRUB that makes the following statement...

The file device.map maps GRUB device names to Linux device names. This is only relevant when running the GRUB shell as a Linux program (command grub). For this purpose, the program reads the file device.map.

And now the coup de grace: Alter the drive assignments in your own device.map (or delete the file entirely) and your computer will still boot your systems just fine. But do that and try running installation commands in the GRUB shell (or with grub-install which uses the GRUB shell), and "things" may happen in some circumstances (recognize this?: "...does not have any corresponding BIOS drive").

So if not for booting, how IS the device.map file used?

I believe the device.map file is only used by the GRUB shell and its front-end shell script, grub-install, in certain circumstances when GRUB is being installed or reinstalled. The device.map file is an editable file and for a good reason. The GRUB manual admits that GRUB can sometimes get confused trying to guess the map between BIOS drives and operating system devices. The device.map file provides a way to correct such errors, I believe, for the purpose of correctly re-installing GRUB. Knowing how GRUB uses the device.map file would therefore be important if it has been edited. It wouldn't do much good to edit the device.map file if the subsequent GRUB installation command ignored it or even worse overwrote it with new information.

By reading the GRUB manual many times and conducting experiments on a test computer, I came to realize the following important things about the device.map file and installing GRUB. The terminal command grub-install [install device] will read the device.map file each time it starts. And starting the GRUB shell like this grub --device-map=/boot/grub/device.map will cause it to read the device.map file. But in other situations, grub-install and the GRUB shell will ignore the device.map file and probe devices instead. For example, starting the GRUB shell with simply grub causes it to ignore the device.map file and probe devices. And when the recheck option is added to grub-install like this grub-install --recheck [install device], it not only ignores the device.map file and probes devices, it will also rewrite an existing device.map with the new information. If the device.map file is missing, the commands grub-install [install device], grub-install --recheck [install device], and grub --device-map=/boot/grub/device.map will all create one after probing devices. The GRUB shell without the --device-map option does not. It is evident to me that choosing the right GRUB installation command or command option after editing the device.map file for mapping errors is just as important as the device.map being accurate.

My experiments with native GRUB (GRUB completely outside an operating system by booting with a GRUB floppy to a grub> prompt) indicated to me that it never uses or creates a device.map file. It always probes devices and, according to the GRUB manual, does so most accurately of all by using BIOS calls as opposed to system calls and libc functions as do the GRUB shell and grub-install which operate only inside an operating system. Native GRUB is your best bet for installing GRUB in cases of IDE/SATA device confusion by GRUB.

Summarizing...

                                         Action with                Action with
GRUB Installation Command                device.map present         device.map missing

grub-install /dev/hdx                    No probe of devices        Probes devices
                                         Reads device.map           Creates device.map
                                         No changes to device.map


grub-install --recheck /dev/hdx          Probes devices             Probes devices 
                                         Ignores device.map         Creates device.map
                                         Creates new device.map


grub                                     Probes devices             Probes devices
                                         Ignores device.map         Does not create device.map
                                         No changes to device.map


grub --device-map=/boot/grub/device.map  No probe of devices        Probes devices
                                         Reads device.map           Creates device.map
                                         No changes to device.map


native GRUB environment                  Always probes devices
                                         Always ignores device.map
                                         Never creates or changes device.map

My Conclusions

Whether GRUB guessed wrongly or a physical change to the drives is the reason, correcting errors in the device.map file is a good thing to do. It should be done for the GRUB shell and its front-end shell script, grub-install, to work properly re-installing GRUB. The device.map file is provided by the GRUB shell for that very purpose according to the GRUB manual. This is the device.map file's true role in resolving booting dilemmas: allowing GRUB to be correctly re-installed when GRUB is otherwise confused by devices. And conversely, there is no reason to edit the device.map file if you do not intend to reinstall GRUB using the GRUB shell or grub-install because just editing the device.map file will not fix anything. And when device.map is edited, it matters which GRUB installation command and option are used to re-install GRUB afterwards. But in the end, the device.map file itself doesn't make any difference in what occurs during the process of booting with the GRUB boot loader, and sometimes may even be a "red herring" unnecessarily complicating booting dilemmas when GRUB does not need to be reinstalled.

[Seve]

Hello:
Great post stoat:

I have no empirical evidence to what I am going to post, so please forgive me. It is solely based on my own experience.
I have 5 disks attached and 5 OS's installed.

From a pure boot perspective, if the device map is incorrect or is missing some devices [on your "master grub install" ] it does not appear to impact the boot process of a lone OS, say Fedora, if that is the "master grub". This appears to be the case, say if you are dual booting and your device.map includes the 2 relevant drives, however others are missing ?

I have only found it to be crucial when you are trying to use that "master grub" to multi-boot a number of different OS's.
Again this is just my experience.
One thing for sure, is that once you have the drives set in your BIOS you do not want to change that order. As you mentioned, I believe, it will confuse grub and any settings you have. Then you are presented with a nightmare if you have more than 2 drives [again, just my experience]

# cat /boot/grub/device.map
(fd0)   /dev/fd0
(hd0)   /dev/hdc
(hd1)   /dev/sda
(hd2)   /dev/sdb
(hd3)   /dev/sdc
(hd4)   /dev/sdd 

# fdisk -l

Disk /dev/hdc: 203.9 GB, 203928109056 bytes
255 heads, 63 sectors/track, 24792 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hdc1   *           1          12       96358+  83  Linux
/dev/hdc2            2611       24792   178176915    5  Extended
/dev/hdc3              13        1228     9767520   83  Linux
/dev/hdc4            1229        2610    11100915   83  Linux
/dev/hdc5            2611       24792   178176883+  83  Linux

Partition table entries are not in disk order

Disk /dev/sda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          13      104391   83  Linux
/dev/sda2              14       12808   102775837+  83  Linux
/dev/sda3           12809       14593    14338012+  83  Linux

Disk /dev/sdb: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1        3824    30716248+   7  HPFS/NTFS
/dev/sdb2            3825       14592    86493960    f  W95 Ext'd (LBA)
/dev/sdb5            3825        6884    24579418+   b  W95 FAT32
/dev/sdb6            6885       14592    61914478+   7  HPFS/NTFS

Disk /dev/sdc: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *           1          13      104391   83  Linux
/dev/sdc2              14        1543    12289725   83  Linux
/dev/sdc3            1544       14338   102775837+  83  Linux
/dev/sdc4           14339       14593     2048287+   5  Extended
/dev/sdc5           14339       14593     2048256   82  Linux swap / Solaris

Disk /dev/sdd: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1   *           1          13      104391   83  Linux
/dev/sdd2              14        1543    12289725   83  Linux
/dev/sdd3            1544        3977    19551105    5  Extended
/dev/sdd4            3978       14593    85273020   83  Linux
/dev/sdd5            1544        3977    19551073+  83  Linux 

# cat /etc/grub.conf
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/sda3
#          initrd /initrd-version.img
#boot=/dev/sda1
default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora Core (2.6.20-1.2944.fc6)
        root (hd0,0)
        kernel /vmlinuz-2.6.20-1.2944.fc6 ro root=LABEL=/1 nodmraid reiserfs i686 rhgb quiet
        initrd /initrd-2.6.20-1.2944.fc6.img
title Fedora Core (2.6.20-1.2933.fc6)
        root (hd0,0)
        kernel /vmlinuz-2.6.20-1.2933.fc6 ro root=LABEL=/1 nodmraid reiserfs i686 rhgb quiet
        initrd /initrd-2.6.20-1.2933.fc6.img
title Fedora Core (2.6.20-1.2925.fc6)
        root (hd0,0)
        kernel /vmlinuz-2.6.20-1.2925.fc6 ro root=LABEL=/1 nodmraid reiserfs pci=nommconf idle=poll i686 rhgb quiet
        initrd /initrd-2.6.20-1.2925.fc6.img
title Fedora Core (2.6.19-1.2911.6.5.fc6)
        root (hd0,0)
        kernel /vmlinuz-2.6.19-1.2911.6.5.fc6 ro root=LABEL=/1 nodmraid reiserfs i686 rhgb quiet
        initrd /initrd-2.6.19-1.2911.6.5.fc6.img
title Fedora Core (2.6.19-1.2911.6.4.fc6)
        root (hd0,0)
        kernel /vmlinuz-2.6.19-1.2911.6.4.fc6 ro root=LABEL=/1 nodmraid reiserfs i686 rhgb quiet
        initrd /initrd-2.6.19-1.2911.6.4.fc6.img
title Fedora Core (2.6.19-1.2911.fc6)
        root (hd0,0)
        kernel /vmlinuz-2.6.19-1.2911.fc6 ro root=LABEL=/1 nodmraid reiserfs i686 rhgb quiet
        initrd /initrd-2.6.19-1.2911.fc6.img

## Test Release of F7 Installation
title Fedora Core 7 Test2
        root (hd3,0)
        rootnoverify (hd3,0)
        chainloader +1

## Fedora Core 64 bit Installation
title Fedora Core 6 X64
        root (hd2,0)
        rootnoverify (hd2,0)
        chainloader +1

## Windows XP Installation
title Windows XP Pro
        root (hd1,0)
        chainloader +1
        map (hd0) (hd1)
        map (hd1) (hd0)
        makeactive

## Debian Etch Installation
title Debian Etch
        root (hd4,0)
        rootnoverify (hd4,0)
        chainloader +1 

In the past I have tried editing my device.map, however, it seems to be in-effective [at least in my case] as it seems difficult to map the drives correctly.
I have found it to be much more effective and reliable to let the --recheck command probe and write it the way grub sees it.

I don't know if this helps you or not

Seve

[VJLinux]

Thanks Stoat for this great post.
I have been rescuing my linux systems and mucking wiht grub for many years now.
But yesterday when my laptop failed and made 2 OS's on it unusable I couldn't rescue them with all the tricks in my bag.
Then I stumbled on your post and in an instant it gave me exact reason for the behavior I was observing on my system.
Repeated grub reinstalls had made the device map totally useless and grub wasn't finding the root disk.
Then after reinstalling grub with --recheck corrected the problem instantly and I could finally boot the system!
I must have read grub manual many times, but never analyzed and understood the way you have!!
Thanks again for sharing this.
God bless you!

- vjlinux