This section assume your system has UEFI support and you wish to boot LFS with UEFI. If your system does not support UEFI or you don't want to use it, you'll need to figure out how to configure the booting process of the system on your own.
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, GRUB2, or LILO.
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. To create a emergency boot device for UEFI, consult section “Create an Emergency Boot Disk” in the BLFS page.
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.
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).
GRUB works by creating an EFI executable in the EFI System Partition (ESP). You can find the ESP with:
fdisk -l | grep 'EFI System'
If no ESP exists on your hard drive (for example, you are building LFS on a fresh new system with a Live CD as the host distro), read the BLFS page for the instruction to create an ESP on your hard drive.
If the ESP is not mounted at /boot/efi
(in the chroot), mount it now:
mkdir -pv /boot/efi mount /boot/efi
The path to the device node is intentionally omitted in the
command. We expect the entry for mounting the ESP to /boot/efi
is already in /etc/fstab
. Add the entry before running the
command if you forgot to create an entry for the ESP in Section 10.2,
“Creating the /etc/fstab File”.
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 each build, whether LFS or some commercial
distro, can access the same boot files and access can be made from
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
.
Install the GRUB files into /boot/grub
and the GRUB EFI executable into
/boot/efi/EFI/BOOT/BOOTAA64.EFI
:
The following command will overwrite BOOTAA64.EFI
. Do not run the command if this is
not desired, for example, if it contains a third party boot
manager. You can backup it with cp as it's a regular file.
grub-install --removable
--removable
may seem
strange here. The UEFI firmware searches EFI executables for boot
loaders in a hardcoded path, EFI/BOOT/BOOTAA64.EFI
in the ESP, and other
boot loader paths listed in the EFI variables. We've not
installed the utilities for manipulating EFI variables so we need
to install the EFI executable into the hardcoded path. The
hardcoded path is usually used by removable devices (for example,
USB thumb devices) so the grub-install option for this
purpose is named --removable
.
UEFI implementation usually prefers the boot loaders with paths recorded in an EFI variable, to the boot loader with the hardcoded search path. You may need to invoke the boot device selection menu or setting interface of your EFI firmware on next boot to explicitly select the bootloader.
Some UEFI implementation may completely skip the hardcoded path
if there are other boot loaders in the same hard drive with paths
recorded in an EFI variable. Then you need to create an EFI
variable for the newly installed boot loader. Install
efibootmgr, and follow
the BLFS instruction to run the grub-install command without
the --removable
option
then.
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)
insmod efi_gop
menuentry "GNU/Linux, Linux 6.10.8-lfs-arm64-r12.2-119-systemd" {
linux /boot/vmlinuz-6.10.8-lfs-arm64-r12.2-119-systemd 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. The grub-install command has embedded
some modules into the main GRUB
image (installed into the MBR or the GRUB BIOS partition) to access
the other modules (in /boot/grub/arm64-efi
) without a chicken-or-egg
issue, so with a typical configuration these two modules are
already embedded and those two insmod commands will do nothing.
But they do no harm anyway, and they may be needed with some rare
configurations.
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.
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
, and replace <UUID of the filesystem where the kernel
is installed>
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=
instead of <filesystem
UUID>
root=PARTUUID=
,
but doing so will require an initramfs, which is beyond the scope
of LFS.
<partition UUID>
The name of the device node for a partition in /dev
may also change (this is less likely than
a GRUB designator change). You can also replace paths to device
nodes like /dev/sda1
with
PARTUUID=
, in
<partition UUID>
/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.
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.