Originally written: 11/5/2012; last update: 7/17/2017
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. It has no GUI (it's a text-mode program), it can't auto-detect Linux boot loaders, and it can't launch BIOS-mode boot loaders, for instance. This simplicity can be a turn-off for those who want "eye candy" or who need certain advanced features; but it's a boon for those who want simplicity.
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 could well be the EFI stub loader, making systemd-boot a good substitute for ELILO, SYSLINUX, GRUB Legacy, or GRUB 2 if you're using a 3.3.0 or later kernel.
Like ELILO and SYSLINUX, systemd-boot requires that its kernels reside on the same partition as the boot program itself. This will normally be the ESP. The same limitation applies to boot loaders for other OSes, such as Windows. Thus, as a practical matter, if you want to use systemd-boot, you must store your kernels on the ESP.
systemd-boot is sparsely documented. (The Arch Linux systemd-boot documentation is more extensive than the documentation on systemd-boot's own page.) The program's simplicity, however, means that it requires relatively little in the way of documentation. Familiarity with the basic principles of Linux boot loader configuration, as exemplified by LILO, ELILO, or GRUB, will be helpful in setting up systemd-boot.
systemd-boot seems to have code related to Secure Boot; however, I have not tested it extensively. The code seems similar to that used by rEFInd (both are derived from code written for PreBootloader by James Bottomley). See the page on Secure Boot for more information on how to deal with Secure Boot.
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 system 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. The first is a global configuration file called loader/loader.conf on the ESP (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. An example 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 "Dealing with Secure Boot"
Return to "Managing EFI Boot Loaders for Linux" main page
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.