Chapter 3: Installation 11
device file
device is a drive specified in the GRUB syntax (see Section 11.1 [Device syntax],
page 41), and file is an OS file, which is normally a device file.
Historically, the device map file was used because GRUB device names had to be
used in the configuration file, and they were derived from BIOS drive numbers. The map
between BIOS drives and OS devices cannot always be guessed correctly: for example,
GRUB will get the order wrong if you exchange the boot sequence between IDE and SCSI
in your BIOS.
Unfortunately, even OS device names are not always stable. Modern versions of
the Linux kernel may probe drives in a different order from boot to boot, and the prefix
(‘/dev/hd*’ versus ‘/dev/sd*’) may change depending on the driver subsystem in use. As
a result, the device map file required frequent editing on some systems.
GRUB avoids this problem nowadays by using UUIDs or file system labels when
generating ‘grub.cfg’, and we advise that you do the same for any custom menu entries
you write. If the device map file does not exist, then the GRUB utilities will assume a
temporary device map on the fly. This is often good enough, particularly in the common
case of single-disk systems.
However, the device map file is not entirely obsolete yet, and there are still some
situations that require it to exist. If necessary, you may edit the file if grub-mkdevicemap
makes a mistake. You can put any comments in the file if needed, as the GRUB utilities
assume that a line is just a comment if the first character is ‘#’.
3.4 BIOS installation
MBR
The partition table format traditionally used on PC BIOS platforms is called the Master
Boot Record (MBR) format; this is the format that allows up to four primary partitions
and additional logical partitions. With this partition table format, there are two ways to
install GRUB: it can be embedded in the area between the MBR and the first partition
(called by various names, such as the "boot track", "MBR gap", or "embedding area", and
which is usually at least 31 KiB), or the core image can be installed in a file system and a
list of the blocks that make it up can be stored in the first sector of that partition.
Each of these has different problems. There is no way to reserve space in the em-
bedding area with complete safety, and some proprietary software is known to use it to
make it difficult for users to work around licensing restrictions; and systems are sometimes
partitioned without leaving enough space before the first partition. On the other hand,
installing to a filesystem means that GRUB is vulnerable to its blocks being moved around
by filesystem features such as tail packing, or even by aggressive fsck implementations, so
this approach is quite fragile; and this approach can only be used if the ‘/boot’ filesystem
is on the same disk that the BIOS boots from, so that GRUB does not have to rely on
guessing BIOS drive numbers.
The GRUB development team generally recommends embedding GRUB before the
first partition, unless you have special requirements. You must ensure that the first partition
starts at least 31 KiB (63 sectors) from the start of the disk; on modern disks, it is often a