systemd-boot

systemd-boot

Although it was included in systemd more than ten years ago, the boot manager systemd-boot (sd-boot for short) is rarely found on desktop systems. If you decide to use sd-boot with a suitable setup and after thorough testing, the changeover is not a major challenge for a somewhat experienced user.

Features

The boot manager sd-boot was developed with the aim of making the boot process fast, simple and secure. The user receives a text-based boot menu. The display does not need any bells and whistles.
In keeping with its name, it is deeply integrated into systemd and accesses the services available there. sd-boot creates a visually minimalist boot menu. Each menu entry is based on a single, separate text file. The configuration for the user interface is rudimentary compared to GRUB and the installation scope is very small.
sd-boot is only available for UEFI hardware. For this, sd-boot requires an ESP (Efi System Ppartition). An additional XBOOTLDR partition is especially recommended if you want to dual-boot with Windows and macOS.

If only the ESP is present, it is mounted under /boot.
For ESP and XBOOTLDR partitions, the ESP is mounted under /efi and the XBOOTLDR partition under /boot.
Both partitions require a VFAT file system.
sd-boot can only boot operating systems from partitions on the same medium. To boot operating systems from other media, use the ChainLoader method to GRUB or another boot loader.

The default boot manager for siduction is GRUB. The ISOs also boot using GRUB.
Starting with siduction 2026.1.0, the cli-installer in all flavors allows you to select sd-boot during installation. This eliminates the need to change to sd-boot later.
sd-boot requires a different initrd than GRUB. The installer creates this automatically. It is important for users to understand that initrds created for GRUB will not boot with sd-boot.

systemd-boot functions:

• Boot from fully encrypted hard disk.
• Support for the XBOOTLDR partition.
• Registering SecureBoot keys.
• Create a menu entry when installing new kernels.
• Boot counting
  In connection with failed boot processes, the boot entry can be removed automatically.
• Support for passing a random seed to the OS.
  This serves to protect against the use of manipulated OS images.

It is also possible to pass commands to sd-boot before a reboot or during the boot process. Information on this can be found in man systemd-boot.

Application scenarios

Suitability with different system configurations and in comparison with GRUB.

sd-boot fully demonstrates its advantages with a simple hardware setup, but fails with operating systems on multiple media. With support for siduction-btrfs, sd-boot is also well suited for installation in the Btrfs file system with simultaneous use of Snapper.
Grub, on the other hand, can be used more universally, is therefore heavyweight and still requires external software. Here too, siduction-btrfs is useful when installing to the Btrfs file system. GRUB is oversized for simple hardware setups.

Installing systemd-boot

Starting with siduction 2026.1.0, you can select the systemd-boot boot manager directly during the initial installation using the cli-installer. If you choose this option, you do not need the following instructions.

Attention
It is essential to make a data backup on an external medium. Work on partitions is necessary to install sd-boot according to the recommendations.

The instructions are based on the standard installation of siduction with the bootmanager GRUB and an ESP (Efi System Ppartition), which is mounted under /boot/efi. This is also the standard for Debian and many Debian derivatives. To switch to sd-boot, you only need the systemd-boot, systemd-boot-tools and systemd-boot-efi packages, along with a few dependencies.
But be careful, first some work on the system is necessary.

System preparation

Partitioning

A significant change of sd-boot compared to the standard installation of siduction with GRUB is the relocation of the directory /boot into one or better two separate partitions. The recommendations of sd-boot are:

• Both ESP and XBOOTLDR:
  ESP
  Partition type “EFI System”, Part-GUID: C12A7328-F81F-11D2-BA4B-00A0C93EC93
  File system: VFAT, mounted under /efi/
  Size: 100 MB
  XBOOTLDR
  Partition type “Linux extended boot”, Part-GUID: BC13C2FF-59E6-4262-A352-B275FD6F7172
  File system: VFAT, mounted under /boot/
  Size: at least 1 GB

  sd.boot bug
  Since systemd 258.2, sd-boot can only read data from the XBOOTLDR partition if the partition has been formatted with vfat.
  systemd-boot fails to use other file system than vfat

• Only ESP:
  (Conditionally recommended, see below.)
  Partition typ “EFI System”, Part-GUID: C12A7328-F81F-11D2-BA4B-00A0C93EC93
  File system: VFAT, mounted under /boot/
  Size: at least 1 GB

• Not recommended:
  ESP mounted under /boot/efi/

Quotes from the boot_loader_specification.

[Quote start]
Note: These partitions are shared among all OS installations on the same disk. Instead of maintaining one boot partition per installed OS (as /boot/ was traditionally handled), all installed OSes use the same place for boot loader menu entries.
[…]
Mounting the ESP to /boot/efi/, as was traditionally done, is not recommended. Such a nested setup complicates an implementation via direct autofs mounts — as implemented by systemd for example —, as establishing the inner autofs will trigger the outer one. Mounting the two partitions via autofs is recommended because the simple VFAT file system has weak data integrity properties and should remain unmounted whenever possible.
[…]
For systems where the firmware is able to read file systems directly, the ESP must — and the MBR boot and GPT XBOOTLDR partition should — be a file system readable by the firmware. For most systems this means VFAT (16 or 32 bit). The same file system type must be used for both partitions.
[Quote end]

Minimum size

If you follow the recommendations of sd-boot and use both the ESP and the XBOOTLDR partition, you can keep the small size of the ESP. If you intend to use only the ESP mounted at /boot, we recommend at least 1 GB.
The XBOOTLDR partition should be at least 1 GB, as sd-boot stores all kernels and initrd in it twice. As prescribed by the standard, once directly under /boot/ and once again under /boot/<entry-token-or-machine-id>/<version>/. This results in 70 to 100 MB for a kernel with initrd. The reason for this is probably the use of VFAT, which does not support symlinks. With several OSes, each with several kernels, the size of 1 GB is borderline and the usual 200 to 300 MB of the ESP are completely unsuitable. This requires a change in partitioning.

We keep the ESP in its previous size and create the XBOOTLDR partition anywhere on the same medium. As already mentioned, at least 1 GB in size, preferably 2 GB. If the UUID of an existing partition changes, the /etc/fstab file must be adjusted. See: Customize the fstab.

Copy data and adapt files

We open a terminal and become ROOT with su.
The lsblk command then displays the type name, type name, and type GUID for both partitions.

# lsblk -n -o NAME,PARTTYPENAME,PARTTYPE /dev/nvme0n1p1 /dev/nvme0n1p4
nvme0n1p1 EFI System          c12a7328-f81f-11d2-ba4b-00a0c93ec93b
nvme0n1p4 Linux extended boot bc13c2ff-59e6-4262-a352-b275fd6f7172

If the output does not match the example shown, we use the cfdisk program to change the partition type.
In the next step we create new directories and copy the directory /boot.

# cd /
# mkdir /efi
# mkdir /grub
# cp -a /boot/* /grub/
# umount /boot/efi/
# rm -r /boot/*

We also backed up the ESP data with the command sequence.
Now we adapt the file /etc/fstab. (Create a backup copy beforehand.)

# cp /etc/fstab /etc/fstab_$(date +%F)

We create a copy of the line with the mount point /boot/efi and only remove the string “/boot” from the original line.
In the copy we write the data for the XBOOTLDR partition with the mount to /boot.
Finally, the changes should look like this.

[...]
UUID=FA62-156D          /efi    vfat   defaults 0 2
UUID=<uuid_of_xbootldr> /boot   ext4   defaults 0 2
[...]

Now we mount the partitions and copy the kernel with accessories to /boot.

# systemctl daemon-reload
# mount /boot/
# mount /efi/
# cp -a /grub/vmlinuz-6.8.9-1-siduction-amd64 /boot/
# cp -a /grub/initrd.img-6.8.9-1-siduction-amd64 /boot/
# cp -a /grub/System.map-6.8.9-1-siduction-amd64 /boot/
# cp -a /grub/config-6.8.9-1-siduction-amd64 /boot/
   # or more simply: cp -a /grub/*-6.8.9-1-siduction-amd64 /boot/

Installation

Once the preparations are complete and the result has been checked, e.g., with the commands ls -l /boot, lsblk, or cfdisk, a single command line is sufficient to add the required packages to our system and install sd-boot to ESP and XBOOTLDR.

# apt install systemd-boot-efi systemd-boot
[...]
Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/efi/EFI/systemd/systemd-bootx64.efi".
Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/efi/EFI/BOOT/BOOTX64.EFI".
Created "/boot/e5cc6ff820c1450c93a29d8723c78cd1".
Random seed file /efi/loader/random-seed successfully installed (32 bytes).
Created EFI boot entry "Linux Boot Manager".

In the firmware UEFI menu, we now find the Linux Boot Manager in first place, which, as the output shows, has been written to the ESP. At the same time, sd-boot has created the boot entries for the Linux Boot Manager in the XBOOTLDR partition.
For each additional OS on the medium, the ‘System preparation’ and the ‘Installation’ are necessary.

Configuration

There are only two places where the configuration for sd-boot is located.
For the Linux Boot Manager it is the file /efi/loader/loader.conf and for the menu entries it is the files with the extension .conf in the directory /boot/loader/entries/.

Linux Boot Manager

The configuration of the Linux Boot Manager only affects the following points
- Display of the menu and timeout - no/yes/duration
- Console mode - value
- Editing the kernel line - yes/no
- Set default boot entry - value

For only one system with one kernel, the configuration file has the following content:

#timeout 3
#console-mode keep

It boots directly into the operating system without displaying a menu, because ‘timeout’ is commented out. The reason: Only one menu item exists so far. After removing the comment character, the menu of a siduction XFCE installation appears.

                    siduction XFCE
            Reboot Into Firmware Interface

If there is more than one OS on the medium, the file /efi/loader/loader.conf contains an additional line default <entry-token-or-machine-id>-* to define the default entry.

timeout 3
#console-mode keep
default e5cc6ff820c1450c93a29d8723c78cd1-*

Menu entries

The configuration files are located in the directory /boot/loader/entries/ and their name corresponds to the format <entry-token-or-machine-id>-<kernelversion>.conf.
sd-boot automatically adds the entries to the menu when additional kernels are installed. With an additional kernel, the menu items also receive the kernel version.

           siduction XFCE (6.8.10-1-siduction-amd64)
           siduction XFCE (6.8.9-1-siduction-amd64)
                Reboot Into Firmware Interface

Of several OS on different partitions, only the one from which sd-boot was installed is automatically listed in the menu. The kernels available there appear in the selection. If you install sd-boot in every OS, these boot entries also find their way into the menu. Here, for example, is UBUNTU.

           siduction XFCE (6.8.10-1-siduction-amd64)
           siduction XFCE (6.8.9-1-siduction-amd64)
                       Ubuntu 24.04 LTS
                Reboot Into Firmware Interface

If, for whatever reason, a menu entry is missing, we can trigger the generation of the entry again at any time. Make sure that the kernel and the config file for the corresponding version are located in the /boot/ directory
From the corresponding OS, the command

dpkg-reconfigure linux-image-6.8.9-1-siduction-amd64

also creates the desired menu entry.

Remove GRUB

If extensive tests with sd-boot were successful, we have to remove GRUB from our system to avoid errors during update and upgrade.

Packages

We open a terminal, become ROOT with su and use the command apt purge to remove the configuration files as well.

# apt purge grub*
 Package lists are read...
 Dependency tree is built...
 Status information is read in...
 The following packages are REMOVED:
 grub-pc-bin* os-prober* grub-btrfs* grub2-common* grub-efi-amd64-bin*
 grub-common* grub-efi-ia32-bin* memtest86+* grub-pc*
 0 updated, 0 reinstalled, 9 to be removed.
 After this operation 0 B disk space will be used additionally.
 Do you want to continue? [Y/n]

After this action, the backup copies we created and two GRUB directories remain. These are
the directory /grub/,
the backup file /etc/fstab_*,
the directory /usr/share/grub/
and the directory /etc/default/grub.d/.

Let’s get rid of the leftovers with

# rm -r /grub/
# rm /etc/fstab_*
# rm -r /usr/share/grub/
# rm -r /etc/default/grub.d/

Clean up UEFI

The siduction boot entry from the installation with GRUB still exists in the firmware. We display the content in the terminal with ROOT rights. (Shortened version)

# efibootmgr
 BootCurrent: 0001
 Timeout: 0 seconds
 BootOrder: 0001,0000,0002,2001,2002
 Boot0000* siduction
 Boot0001* Linux Boot Manager
 Boot0002* EFI Hard Drive
 Boot2001* EFI USB Device
 Boot2002  EFI Network RC

The first command removes the GRUB entry.
The second command then deletes the corresponding directory from /efi/.

# efibootmgr -b 0000 -B
# rm -r /efi/EFI/siduction/

systemd-boot and Btrfs

The Btrfs file system, especially in conjunction with snapper, offers the possibility of restoring a defective system to a previous state. In this context, the relocation of the /boot directory to a separate partition required by sd-boot is a hindrance. The /boot directory is an essential part of the operating system and should not be moved to a partition or subvolume in connection with Btrfs. This is because it is not covered by snapshots of the root file system.

Nevertheless, siduction with the package siduction-btrfs is able to create menu entries for all kernels contained in the rollback target after a rollback. In addition, the standard boot entry then boots into the rollback target. However, menu entries for other snapshots are not available.

The siduction-btrfs package is not tied to a specific boot manager. This means that the user can decide for themselves whether they want to switch to sd-boot when installing the system on Btrfs.

Further information

man systemd-boot
boot_loader_specification