10.4. Using GRUB to Set Up the Boot Process

10.4.1. Introduction

Ensure that an emergency boot disk is ready to “rescue” the computer if the computer becomes unusable (un-bootable). If you do not already have a boot device, you can create one. In order for the procedure below to work, you need to jump ahead to BLFS and install xorriso from the libisoburn package.

cd /tmp
grub-mkrescue --output=grub-img.iso
xorriso -as cdrecord -v dev=/dev/cdrw blank=as_needed grub-img.iso

10.4.2. GRUB Naming Conventions

GRUB uses its own naming structure for drives and partitions in the form of (hdn,m), where n is the hard drive number and m is the partition number. The hard drive numbers start from zero, but the partition numbers start from one for normal partitions (from five for extended partitions). Note that this is different from earlier versions where both numbers started from zero. For example, partition sda1 is (hd0,1) to GRUB and sdb3 is (hd1,3). In contrast to Linux, GRUB does not consider CD-ROM drives to be hard drives. For example, if using a CD on hdb and a second hard drive on hdc, that second hard drive would still be (hd1).

10.4.3. Setting Up the Configuration

If booting the system via BIOS, GRUB works by writing a stub to the first sector (named the Master Boot Record, or MBR) of the hard disk. This area is not part of any file system. The BIOS loads and executes the content of MBR, then the stub loads the main GRUB image from the BIOS Boot Partition. The GRUB image is stored as raw data instead of a file (there must be no file system on the BIOS Boot Partition), so the stub doesn't need to support any file system and it can be made small enough to fit in the MBR.

If booting the system via UEFI, GRUB works by storing the main GRUB image as a PE-COFF executable file at a standard location in the EFI System Partition. The EFI firmware loads the file at the standard location and executes it.

Many GRUB functions (including booting the Linux kernel) are not included in the main GRUB image. Instead, they are stored in a file system as GRUB modules. That file system is usually mounted in a way that the GRUB modules can be accessed in /boot/grub on most Linux distributions. To avoid the chicken-and-egg problem, grub-install embeds the modules necessary to access this file system into the main GRUB image, so it can find and load other modules.

The location of the boot partition is a choice of the user that affects the configuration. One recommendation is to have a separate small (suggested size is 200 MB) partition just for boot information. That way for each build, whether it's LFS or a commercial distro, it can access the same boot files and can access can any booted system. If you choose to do this, you will need to mount the separate partition, move all files in the current /boot directory (e.g. the Linux kernel you just built in the previous section) to the new partition. You will then need to unmount the partition and remount it as /boot. If you do this, be sure to update /etc/fstab.

Leaving /boot on the current LFS partition will also work, but configuration for multiple systems is more difficult.

Using the above information, determine the appropriate designator for the root partition (or boot partition, if a separate one is used). For the following example, it is assumed that the root (or separate boot) partition is sda2.

The following sections go over how to boot with BIOS and UEFI. The GRUB installations for BIOS, 64-bit UEFI, and 32-bit UEFI can coexist and share the same configuration. The images and data live at different locations, so you can create both the BIOS Boot Partition and the EFI System Partition, and install GRUB for all the supported firmware types (i.e. running three grub-install commands). If you are unsure about your firmware type, or you plan to move the hard drive to a different computer, this is something you can do as a blanket strategy.

10.4.4. Creating the GRUB Configuration File

Generate /boot/grub/grub.cfg:

cat > /boot/grub/grub.cfg << "EOF"
# Begin /boot/grub/grub.cfg
set default=0
set timeout=5

insmod part_gpt
insmod ext2

set root=(hd0,2)

# For UEFI
insmod efi_gop
insmod efi_uga

set gfxpayload=1024x768x32

menuentry "GNU/Linux, Linux 6.19.8-lfs-r13.0-27-systemd" {
        linux   /boot/vmlinuz-6.19.8-lfs-r13.0-27-systemd root=/dev/sda2 ro
}
EOF

The insmod commands load the GRUB modules named part_gpt, ext2, efi_gop, and efi_uga. Despite the naming, ext2 actually supports ext2, ext3, and ext4 filesystems. On UEFI systems, efi_gop and efi_uga are for video support. GOP, or Graphics Output Protocol, is the modern approach. UGA, or UGA Draw Protocol, is a legacy way of handling it. In a typical configuration, these four modules are already embedded in the main GRUB image by grub-install, and those four insmod commands will do nothing; However, they do no harm anyway, and they may be needed with some rare configurations.

The set gfxpayload=1024x768x32 command sets the resolution and color depth of the VESA framebuffer to be passed to the kernel. It's necessary for the kernel SimpleDRM driver to use the VESA framebuffer. You can use a different resolution or color depth value which better suits for your monitor. This line does nothing when the system is booted via UEFI, but it does no harm anyway.

GRUB is an extremely powerful program and it provides a tremendous number of options for booting from a wide variety of devices, operating systems, and partition types. There are also many options for customization such as graphical splash screens, playing sounds, mouse input, etc. The details of these options are beyond the scope of this introduction.