How Linux Uses systemd-boot as a GRUB Alternative

This article examines how the Linux operating system uses systemd-boot as a streamlined, modern replacement for the traditional Grand Unified Bootloader (GRUB). It covers the architecture of systemd-boot, how it interacts with Unified Extensible Firmware Interface (UEFI) firmware, its configuration mechanisms via the Boot Loader Specification, and why many distributions and users prefer its minimal footprint over GRUB’s complex feature set.

Understanding systemd-boot

Originally developed as Gummiboot, systemd-boot is a minimal UEFI boot manager integrated directly into the systemd suite. Unlike GRUB, which is a full-featured bootloader capable of running on legacy BIOS systems and loading file system drivers, systemd-boot operates strictly on UEFI systems. It offloads low-level hardware initialization and file access entirely to the UEFI firmware itself.

Because UEFI can natively read FAT file systems and execute UEFI binaries, systemd-boot does not need to duplicate operating system drivers. Instead, it serves as a lightweight menu selector that directs the UEFI firmware to execute the Linux kernel directly using the kernel's built-in EFI stub loader (CONFIG_EFI_STUB).

Architecture and File System Requirements

To utilize systemd-boot, the Linux system requires an EFI System Partition (ESP) formatted as FAT32, or a dedicated extended boot partition (XBOOTLDR). Because systemd-boot relies on UEFI to read files:

  1. Kernel and Initramfs Placement: The Linux kernel (vmlinuz) and initial RAM disk (initramfs) must reside on a partition the UEFI firmware can read—typically mounted at /efi, /boot, or /boot/efi.
  2. Directory Structure: systemd-boot expects files organized under standard paths:
    • /EFI/systemd/: Contains the systemd-boot binary.
    • /EFI/BOOT/: Often contains the fallback boot binary (BOOTX64.EFI).
    • /loader/: Contains global configuration settings.
    • /loader/entries/: Contains individual configuration files for each kernel.

Configuration via the Boot Loader Specification (BLS)

One of the primary ways Linux uses systemd-boot as a cleaner alternative to GRUB is through standard, human-readable configuration files defined by the Boot Loader Specification (BLS).

GRUB relies on complex shell scripts (/etc/grub.d/ and update-grub) that parse system parameters to generate a massive, monolithic /boot/grub/grub.cfg file. In contrast, systemd-boot uses modular, drop-in text files.

Global Configuration

The primary settings file, located at /loader/loader.conf, controls general behavior:

default arch.conf
timeout 4
console-mode max
editor no

Entry Configurations

Each kernel has its own dedicated entry file inside /loader/entries/, such as /loader/entries/linux.conf:

title   Arch Linux
linux   /vmlinuz-linux
initrd  /initramfs-linux.img
options root=UUID=1234-5678-90ab rw quiet

Because each kernel installation is represented by a standalone file, adding, updating, or removing a kernel never risks corrupting the configuration of other kernels.

Managing the Bootloader in Linux

Linux systems manage systemd-boot using the native command-line utility bootctl:

Kernel Automation with kernel-install

To match the automated updates typically handled by grub-mkconfig, distributions using systemd-boot utilize the kernel-install framework.

When a package manager installs a new kernel:

  1. The kernel package manager hook executes kernel-install add <kernel-version> <kernel-image>.
  2. The kernel-install script copies the kernel binary and generated initramfs directly to the ESP.
  3. It automatically generates a matching .conf file inside /loader/entries/ with the appropriate root flags and kernel parameters.

Key Advantages Over GRUB

Linux distributions and administrators deploy systemd-boot over GRUB for several practical reasons: