4 Installation ************** In order to install GRUB as your boot loader, you need to first install the GRUB system and utilities under your UNIX-like operating system (*note Obtaining and Building GRUB::). You can do this either from the source tarball, or as a package for your OS. After you have done that, you need to install the boot loader on a drive (floppy or hard disk) by using the utility 'grub-install' (*note Invoking grub-install::) on a UNIX-like OS. GRUB comes with boot images, which are normally put in the directory '/usr/lib/grub/-' (for BIOS-based machines '/usr/lib/grub/i386-pc'). Hereafter, the directory where GRUB images are initially placed (normally '/usr/lib/grub/-') will be called the "image directory", and the directory where the boot loader needs to find them (usually '/boot') will be called the "boot directory". 4.1 Installing GRUB using grub-install ====================================== For information on where GRUB should be installed on PC BIOS platforms, *note BIOS installation::. In order to install GRUB under a UNIX-like OS (such as GNU), invoke the program 'grub-install' (*note Invoking grub-install::) as the superuser ("root"). The usage is basically very simple. You only need to specify one argument to the program, namely, where to install the boot loader. The argument has to be either a device file (like '/dev/hda'). For example, under Linux the following will install GRUB into the MBR of the first IDE disk: # grub-install /dev/sda Likewise, under GNU/Hurd, this has the same effect: # grub-install /dev/hd0 But all the above examples assume that GRUB should put images under the '/boot' directory. If you want GRUB to put images under a directory other than '/boot', you need to specify the option '--boot-directory'. The typical usage is that you create a GRUB boot floppy with a filesystem. Here is an example: # mke2fs /dev/fd0 # mount -t ext2 /dev/fd0 /mnt # mkdir /mnt/boot # grub-install --boot-directory=/mnt/boot /dev/fd0 # umount /mnt Some BIOSes have a bug of exposing the first partition of a USB drive as a floppy instead of exposing the USB drive as a hard disk (they call it "USB-FDD" boot). In such cases, you need to install like this: # losetup /dev/loop0 /dev/sdb1 # mount /dev/loop0 /mnt/usb # grub-install --boot-directory=/mnt/usb/bugbios --force --allow-floppy /dev/loop0 This install doesn't conflict with standard install as long as they are in separate directories. Note that 'grub-install' is actually just a shell script and the real task is done by other tools such as 'grub-mkimage'. Therefore, you may run those commands directly to install GRUB, without using 'grub-install'. Don't do that, however, unless you are very familiar with the internals of GRUB. Installing a boot loader on a running OS may be extremely dangerous. On EFI systems for fixed disk install you have to mount EFI System Partition. If you mount it at '/boot/efi' then you don't need any special arguments: # grub-install Otherwise you need to specify where your EFI System partition is mounted: # grub-install --efi-directory=/mnt/efi For removable installs you have to use '--removable' and specify both '--boot-directory' and '--efi-directory': # grub-install --efi-directory=/mnt/usb --boot-directory=/mnt/usb/boot --removable 4.2 Making a GRUB bootable CD-ROM ================================= GRUB supports the "no emulation mode" in the El Torito specification(1) (*note Making a GRUB bootable CD-ROM-Footnote-1::). This means that you can use the whole CD-ROM from GRUB and you don't have to make a floppy or hard disk image file, which can cause compatibility problems. For booting from a CD-ROM, GRUB uses a special image called 'cdboot.img', which is concatenated with 'core.img'. The 'core.img' used for this should be built with at least the 'iso9660' and 'biosdisk' modules. Your bootable CD-ROM will usually also need to include a configuration file 'grub.cfg' and some other GRUB modules. To make a simple generic GRUB rescue CD, you can use the 'grub-mkrescue' program (*note Invoking grub-mkrescue::): $ grub-mkrescue -o grub.iso You will often need to include other files in your image. To do this, first make a top directory for the bootable image, say, 'iso': $ mkdir iso Make a directory for GRUB: $ mkdir -p iso/boot/grub If desired, make the config file 'grub.cfg' under 'iso/boot/grub' (*note Configuration::), and copy any files and directories for the disc to the directory 'iso/'. Finally, make the image: $ grub-mkrescue -o grub.iso iso This produces a file named 'grub.iso', which then can be burned into a CD (or a DVD), or written to a USB mass storage device. The root device will be set up appropriately on entering your 'grub.cfg' configuration file, so you can refer to file names on the CD without needing to use an explicit device name. This makes it easier to produce rescue images that will work on both optical drives and USB mass storage devices. (1) El Torito is a specification for bootable CD using BIOS functions. 4.3 The map between BIOS drives and OS devices ============================================== If the device map file exists, the GRUB utilities ('grub-probe', etc.) read it to map BIOS drives to OS devices. This file consists of lines like this: (DEVICE) FILE DEVICE is a drive specified in the GRUB syntax (*note Device syntax::), 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 it is used for overriding when current environment is different from the one on boot. Most common case is if you use a partition or logical volume as a disk for virtual machine. 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 '#'. 4.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 embedding 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 performance advantage to align partitions on larger boundaries anyway, so the first partition might start 1 MiB from the start of the disk. GPT === Some newer systems use the GUID Partition Table (GPT) format. This was specified as part of the Extensible Firmware Interface (EFI), but it can also be used on BIOS platforms if system software supports it; for example, GRUB and GNU/Linux can be used in this configuration. With this format, it is possible to reserve a whole partition for GRUB, called the BIOS Boot Partition. GRUB can then be embedded into that partition without the risk of being overwritten by other software and without being contained in a filesystem which might move its blocks around. When creating a BIOS Boot Partition on a GPT system, you should make sure that it is at least 31 KiB in size. (GPT-formatted disks are not usually particularly small, so we recommend that you make it larger than the bare minimum, such as 1 MiB, to allow plenty of room for growth.) You must also make sure that it has the proper partition type. Using GNU Parted, you can set this using a command such as the following: # parted /dev/DISK set PARTITION-NUMBER bios_grub on If you are using gdisk, set the partition type to '0xEF02'. With partitioning programs that require setting the GUID directly, it should be '21686148-6449-6e6f-744e656564454649'. *Caution:* Be very careful which partition you select! When GRUB finds a BIOS Boot Partition during installation, it will automatically overwrite part of it. Make sure that the partition does not contain any other data.