10.4 Using GRUB to Set Up the Boot Process

10.4.1 Introduction

Warning

Configuring GRUB incorrectly can render your system inoperable without an alternate boot device such as a CD-ROM or bootable USB drive. This section is not required to boot your LFS system. You may just want to modify your current boot loader, e.g. Grub-Legacy or GRUB2.

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 Turn off Secure Boot

LFS does not have the essential packages to support Secure Boot. To set up the boot process following the instructions in this section, Secure Boot must be turned off from the configuration interface of the firmware. Read the documentation provided by the manufacturer of your system to find out how to turn off Secure Boot support.

10.4.3 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.4 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: EFI/BOOT/BOOTX64.EFI (or EFI/BOOT/BOOTIA32.EFI for i386-efi). The UEFI firmware loads it from the standard location and executes it, launching GRUB.

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. In doing so, not just LFS, but any Linux distribution, can access the same boot files, and in turn 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.

Note

If the host distro utilizes a separate partition for /boot and you want the LFS system to use that partition for /boot as well, just mount the partition at $LFS/boot in the host distro. The Linux kernel supports mounting one partition at multiple mount points.

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

For examples and more information on boot partition layouts, looking at Section 2.4, “Creating a New Partition” may be informative.

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.

Note

If you're doing UEFI boot but have created the Grub BIOS partition, it may be a good idea to run the command for BIOS in case UEFI booting does not work as expected.

Note

If you only need to install GRUB for one boot method, you don't have to run commands for both methods. You can just run the command for the boot method you need.

10.4.4.1 Booting With BIOS

For booting with BIOS, make sure the boot partition is mounted (if using a separate one) and the BIOS Boot partition exists. After that, install the GRUB files into /boot/grub and set up the boot track:

Warning

The following command will overwrite the current boot loader. Do not run the command if this is not desired, for example, if using a third party boot manager to manage the MBR.

grub-install /dev/sda --target=i386-pc

10.4.4.2 Booting With UEFI

For booting with UEFI, make sure the boot partition is mounted (if using a separate one) and the EFI System Partition is mounted at /boot/efi. After that, install the GRUB files into /boot/grub and the main GRUB image at /boot/efi/EFI/BOOT/BOOTX64.EFI:

Warning

The following command will overwrite the /boot/efi/EFI/BOOT/BOOTX64.EFI file. If it already exists, it's likely that it's the entry of another boot loader (for example the GRUB installation from the host distro, or the Windows Boot Manager). Backup the file so it can be restored later or loaded as a secondary boot loader by the new GRUB installation from LFS.

grub-install --target=x86_64-efi --removable

The command above assumes that you have 64-bit UEFI firmware. If you want to make the system bootable on 32-bit UEFI firmware, run the command with x86_64-efi replaced by i386-efi.

The --removable option makes grub-install use the standard location, EFI/BOOT/BOOTX64.EFI (or EFI/BOOT/BOOTIA32.EFI for i386-efi), instead of the location GRUB prefers (EFI/GRUB/GRUBX64.EFI or EFI/GRUB/GRUBIA32.EFI). Using a non-standard location would result in the location in a EFI variable be recorded, but LFS lacks the BLFS package efibootmgr, which is needed by GRUB to record the location into the EFI variable.

Note

Some UEFI firmware implementations, while rare, skip the standard EFI path. Such systems most of the time are old, like Lenovo ThinkPads or HP desktops/laptops. When the boot entry is missing in the firmware setup, you will need to install the BLFS package efibootmgr to create a boot entry for UEFI. If it's easier, the package can be installed via the distribution's package manager, if applicable, and used on the host instead of on the LFS system. This can prevent the need for downloading more tarballs onto the LFS system for now.

First install the package, then mount the EFI variable file system if it isn't already mounted:

mountpoint /sys/firmware/efi/efivars ||
  mount -v -t efivarfs efivarfs /sys/firmware/efi/efivars

Now create a boot entry for the EFI:

efibootmgr -c -d /dev/sd<x> \
  -p <y> -L "LFS" -l '\EFI\BOOT\BOOT<X64>.EFI'

The /dev/sd<x> drive should be the device node for the disk where the ESP exists. The <y> partition number should match the number of the ESP. If the ESP is on /dev/sda2, then the partition number would be 2. If you are using 32-bit UEFI, replace <X64> with IA32.

Some (broken) firmware may require additional parameters for efibootmgr, like --full-dev-path or -e 1 -E. Read the man page efibootmgr(8) for details.

Now unmount the EFI variable file system:

umount -v /sys/firmware/efi/efivars

10.4.5 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)
set gfxpayload=1024x768x32

menuentry "GNU/Linux, Linux 7.1.8" {
        linux   /boot/vmlinuz-7.1.8 root=/dev/sda2 ro
}
EOF

The insmod commands load the GRUB modules named part_gpt and ext2. Despite the naming, ext2 actually supports ext2, ext3, and ext4 filesystems. In a typical configuration, the part_gpt and ext2 modules are already embedded in the main GRUB image by grub-install, and the insmod commands for them 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.

Note

From GRUB's perspective, the kernel files are relative to the partition used. If you used a separate /boot partition, remove /boot from the above linux line. You will also need to change the set root line to point to the boot partition.

Note

The GRUB designator for a partition may change if you added or removed some disks (including removable disks like USB thumb devices). The change may cause boot failure because grub.cfg refers to some “old” designators. If you wish to avoid such a problem, you may use the UUID of a partition and the UUID of a filesystem instead of a GRUB designator to specify a device. Run lsblk -o UUID,PARTUUID,PATH,MOUNTPOINT to show the UUIDs of your filesystems (in the UUID column) and partitions (in the PARTUUID column). Then replace set root=(hdx,y) with search --set=root --fs-uuid <UUID of the filesystem where the kernel is installed>, and replace root=/dev/sda2 with root=PARTUUID=<UUID of the partition where LFS is built>.

Note that the UUID of a partition is completely different from the UUID of the filesystem in this partition. Some online resources may instruct you to use root=UUID=<filesystem UUID> instead of root=PARTUUID=<partition UUID>, but doing so will require an initramfs, which is beyond the scope of LFS.

The name of the device node for a partition in /dev may also change (very frequently on some systems with multiple NVME disks). You can also replace paths to device nodes like /dev/sda1 with PARTUUID=<partition UUID>, in /etc/fstab, to avoid a potential boot failure in case the device node name has changed.

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.

Caution

There is a command, grub-mkconfig, that can write a configuration file automatically. It uses a set of scripts in /etc/grub.d/ and will destroy any customizations that you make. These scripts are designed primarily for non-source distributions and are not recommended for LFS. If you install a commercial Linux distribution, there is a good chance that this program will be run. Be sure to back up your grub.cfg file.