Originally written: 11/5/2012; last update: 7/7/2018
This Web page is provided free of charge and with no annoying outside ads; however, I did take time to prepare it, and Web hosting does cost money. If you find this Web page useful, please consider making a small donation to help keep this site up and running. Thanks!
| Donate $1.00 | Donate $2.50 | Donate $5.00 | Donate $10.00 | Donate another value |
This page is part of my Managing EFI Boot Loaders for Linux document. If a Web search has brought you to this page, you may want to start at the beginning.
The systemd-boot boot manager is, as the name implies, part of the Linux systemd startup system. This boot manager was previously known as gummiboot, which is German for rubber boat. Under either name, it is, like rEFIt and rEFInd, a boot manager, not a boot loader; you can use systemd-boot to select which OS to boot or to launch a 3.3.0 or later kernel, but not to launch another OS's kernel. Despite its linkage to systemd, systemd-boot can be used even if you don't use systemd; and if your distribution uses systemd (as most do), you can use a boot manager other than systemd-boot.
Compared to rEFIt and rEFInd, systemd-boot is a very simple boot manager. Overall, conditions when you might want to consider using systemd-boot include:
Conditions in which you should probably not use systemd-boot include:
Because systemd-boot is a boot manager and not a boot loader, you'll need to use a separate boot loader to launch Linux. In practice, this is likely to be the EFI stub loader. Although you could use systemd-boot to chainload to GRUB 2 or some other boot loader, there would be little advantage to using systemd-boot in such a configuration.
systemd-boot is sparsely documented. (The Arch Linux systemd-boot documentation is more extensive than the documentation on systemd-boot's own page.)
Overall, systemd-boot is a good choice for those wanting a minimal boot experience and who don't mind some manual configuration, both when installing the boot program and when updating kernels. As a practical matter, it's a logical successor to ELILO and SYSLINUX; although they are boot loaders, whereas systemd-boot is a boot manager, in practice all three will be set up and configured in a similar way. The biggest advantage of systemd-boot is that it's under active development. If your needs are more complex (including a need to boot a kernel from a partition other than the ESP) or if you want to deal less with reconfiguration whenever you update a kernel, GRUB 2 or rEFInd will be a better option.
You can install systemd-boot just like any other boot loader, as described on the EFI Boot Loader Installation page. As described shortly, though, you should be aware that systemd-boot's configuration files are placed strangely.
If your computer uses systemd to manage its startup process, the bootctl program can be used to install systemd-boot:
bootctl --path=/boot/efi install
You should change /boot/efi to wherever the ESP is mounted on your system, of course. This command installs systemd-bootx64.efi to /boot/efi/EFI/systemd and also places a copy of the boot loader in the fallback boot loader position (blindly overwriting anything that had been in that location). It also adds a boot entry using efibootmgr, so the system should launch systemd-boot the next time you reboot. This setup process creates a template loader.conf file, as described shortly, but it does not create configuration files for individual kernels or OS boot loaders, so the system may not be bootable until you've set up these files.
If you prefer to compile systemd-boot from source code, you can do so. This will require aquiring the entire systemd source code tree. The git download command is git clone https://github.com/systemd/systemd.git. You must have git installed for this to work. You'll also have to install GNU-EFI, which is usually available in a package called gnu-efi.
systemd-boot uses a series of configuration files, in two categories:
The global configuration file is typically /boot/efi/loader/loader.conf under Linux. Note that this file does not reside in the same directory as the systemd-bootx64.efi file unless you place it in an odd location for an EFI boot loader (namely, the loader directory on the ESP). The loader.conf file supports just two options: timeout to set a timeout value and default to set a default boot option. When first created via bootctl, the timeout value is commented out, which causes systemd-boot to launch its default option without delay unless a keypress is detected on program launch. The default option specifies a pattern that's matched against the titles in the individual loaders' entries. An example loader.conf file looks like this:
timeout 10 default Fedora*
systemd-boot automatically detects a few boot loaders and programs:
Beyond these entries, you must create entries for Linux kernels or other boot loaders by creating configuration files whose names end in .conf in the ESP's loader/entries directory. For instance, you might create files called loader/entries/fedora.conf and loader/entries/custom-kernel.conf. These files include keywords to set a title (title), to launch a non-Linux EFI program (efi), to launch a Linux kernel with EFI stub support (linux), to pass options to a Linux kernel or other EFI program (options), and to specify an initial RAM disk (initrd). An example looks something like this:
title Fedora 26 linux /vmlinuz-4.11.9-300.fc26.x86_64 initrd /initramfs-4.11.9-300.fc26.x86_64.img options ro root=/dev/sda7 quiet
You should include only one definition per configuration file in loader/entries; each file generates one menu entry. Thus, a system with many kernels or OSes will have several configuration files; but distributions should be able to maintain their configurations without stepping on each others' toes. In fact, that's part of the point of systemd-boot and the associated Boot Loader Specification: With systemd-boot installed, all distributions can manage their own boot loader entries merely by dropping configuration files into a standard directory.
systemd-boot enables you to adjust some of its defaults by setting EFI variables stored in NVRAM. Some keys, such as d (set the default option), + (increase the timeout), and - (decrease the timeout), enable you to adjust these options from within systemd-boot. Others can be accessed from directories called /sys/firmware/efi/*-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f, where * is a variable name, such as LoaderTicksInit. The systemd-boot Web page describes the meaning of these variables. A text-mode or GUI utility to adjust these variables from Linux would be useful, but does not yet exist, as far as I know.
When systemd-boot is launched, you'll see a text-mode list of boot options, as shown here:
As you might expect, you can move the selection around by using the arrow keys and launch your selection by pressing the Enter key. Typing e starts a line editor with which you can edit your boot options, uppercase Q quits from systemd-boot, v shows the systemd-boot and firmware version, and F1 summarizes the keys' functions.
My experience with this is limited, but it appears that some distributions, at least, will try to maintain your systemd-boot configuration once it's installed. Specifically, after setting up Fedora 26 to use systemd-boot (reconfiguring it to mount the ESP at /boot), I discovered new configuration files for new kernels after a system upgrade. I don't know how widespread such features are, though. If you use systemd-boot in conjunction with ELILO or some other boot loader, you may be able to leave the systemd-boot configuration alone; but of course you'll need to maintain the other boot loader.
Go on to "Using fallback.efi"
Return to "Managing EFI Boot Loaders for Linux" main page
copyright © 2012–2018 by Roderick W. Smith
If you have problems with or comments about this web page, please e-mail me at rodsmith@rodsbooks.com. Thanks.
Return to my main Web page.