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...
Quote:
|
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...
Quote:
|
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...
Code:
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.
Linear Mode
