Boot Loader

systemd-boot

systemd comes with systemd-boot already, so no additional packages need to be installed.

Install

ATTENTION: By default, systemd-boot will install itself to either of the well-known ESP locations, e.g. /efi, /boot, or /boot/efi. If your ESP is located somewhere else pass the localtion with the --esp-path parameter.

InstallTo install systemd-boot to your EFI System Partition and set it ascreate a boot loader entry named "Linux Boot Manager" in your firmware:

bootctl install

This will copy /usr/lib/systemd/boot/efi/systemd-bootx64.efi to $ESP/EFI/systemd/systemd-bootx64.efi and $ESP/EFI/BOOT/BOOTX64.EFI.

NOTE: If a signed version of systemd-bootx64.efi exists as systemd-bootx64.efi.signed in the same directory, bootctl copies the signed file instead.

Configure

systemd-boot has two kinds of configs:

• one for the loader itself located at $ESP/loader/loader.conf: Configuration file for the boot loader itself
• one for each individual boot entry located at $ESP/loader/entries/*.conf: Configuration files for individual boot entries

LoaderBoot loader config

NOTE: For a full list of options and their explanation refer to loader.conf(5) § OPTIONS

An example loader configuration could look something like this:

ATTENTION: Only spaces are accepted as white-space characters for indentation, do not use tabs!

default         arch    # pre-selects entry from $ESP/loader/entries/arch.conf
timeout         3       # 3 seconds before the default entry is booted
auto-entries    1       # shows boot entries which were auto-detected
auto-firmware   1       # shows entry "Reboot into firmware"
console-mode    keepmax     # picks the highest-numbered mode available

Boot entry config

NOTE:SEE ALSO: For a full list of options and their explanation refer to theThe Boot Loader Specification. Allfor pathsa arecomprehensive relative to the pathoverview of yourwhat ESP.systemd-boot implements.

BootloaderAvailable parameters in boot entry forconfig the main kernel, located at $ESP/loader/entries/arch.conf (assuming $ESP is mounted at /boot):files:

title	Arch Linux
linux	/vmlinuz-linux
initrd	/amd-ucode.img
initrd	/initramfs-linux.img
options	root=/dev/mapper/vg0-lv_root rw quiet splash rootflags=subvol=@

UnifiedType kernel1 (text file based)

NOTE: As of mkinitramfs v38, the CPU microcode is embedded in the initramfs and it is no longer necessary to specify CPU microcode images on a separate initrd line before the actual initramfs.

Type 1 entries specify their parameters in *.conf files under §ESP/loader/entries/.

All paths in these configs are relative to the ESP, e.g. if the ESP is mounted at /boot a boot loader entry located at $ESP/loader/entries/arch.conf would look like this:

title	Arch Linux
linux	/vmlinuz-linux
initrd	/initramfs-linux.img
options	rd.luks.name=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX=cryptroot root=/dev/mapper/cryptroot rw

Type 2 (EFI executable)

When using a unified kernel image, any image ending with *.efi placed under $ESP/EFI/Linux/ will be automatically picked up by systemd-boot along with the metadata embedded in that image (e.g. title, version, etc.)

In case you storeIf your imagesUKIs someplaceare stored somewhere else, you will need toa supply the efi key instead of initrd in yourloader entry *.conf: file with an efi key pointing systemd-boot to the location of the *.efi file on the ESP:

title	Arch Linux
efi     /EFI/Arch/linux.efi

EFISTUB

EFISTUB is a method of booting the kernel directly as an EFI executable by the firmware without the need to use a boot loader. This can be useful in cases where you want to reduce the attack surface a boot loader can introduce, or you intend to only ever boot one image. However, some UEFI firmware implementations can be flaky, so this isn't always practical.

Install

To be able to manipulate EFI boot variables install efibootmgr:

pacman -S efibootmgr

Configure

efibootmgr

efibootmgr -Bb XXXX

To create a new entry efibootmgr needs to know the disk and partition where the kernel image resides on the ESP.

In this exampleexample, the ESP is the first partition of the block device /dev/nvme0n1. Kernel parameters are part of the -u option. The partition that holds your root file system needs to be passed as a persistent block device name (see: Arch Wiki: Persistent block device naming).

NOTE: If you use LVM,LVM or LUKS, you can supply the device mapper pathsname assince thesethat already areis persistent.

You can get the persistent block device nameidentifier of a file system with the blkid command, i.e. to get the UUID of the secondroot partitionfile on /dev/nvme0n1:system:

# /dev/nvme0n1p1 is the ESP, hence /dev/nvme0n1p2 is the root fs
blkid -s UUID -o value /dev/nvme0n1p2

For ease of scriptability, save the values to environment variables:

ASSUMPTIONS: rootfs is on /dev/nvme0n1, there is a swap partition, file system is btrfs and microcode is AMD.

export ROOT=$(blkid -s UUID -o value /dev/nvme0n1p2)
export SWAP=$(blkid -s UUID -o value /dev/nvme0n1p3)
export CMDL="root=UUID=$ROOT resume=UUID=$SWAP rw quiet splash rootflags=subvol=@ add_efi_memmap initrd=\\\amd-ucode.img initrd=\\\initramfs-linux.img"

Then create the boot entry tousing load the kernel directly:efibootmgr:

efibootmgr -c -L "Arch Linux" -d /dev/nvme0n1 -p 1 -l /vmlinuz-linux -u $CMDL -v

Unified kernel image

When using a unified kernel image you can instead just point to the imageUKI without specifyingneeding to specify any kernel parameters via the -u option:option (as these will be part of the UKI already):

ATTENTION: If Secure Boot is enabled and the command line parameters are embedded in the unifiedUKI, kernelthe image,embedded anycommand attemptline toparameters overridewill themalways bytake supplyingprecedence, even if you pass additional parameters with the -u option anyways will be ignored.option.

efibootmgr -c -L "Arch Linux" -d /dev/nvme0n1 -p 1 -l "EFI\Linux\archlinux-linux.efi" -v