SystemD Leviathan Part 4: Boot Loader

Published on October 10, 2023 at 10:16 am by LEW

Introduction

In this post we will be taking a look at the using systemd boot loader subsystem as a replacement for a more traditional boot loader, like grub (GRand Unified Boot loader).

While many Linux Distributions use grub as the default boot loader, systemd provides its own boot loader subsystem, which is installed by default with the rest of systemd. Again part of the systemd interface that sits on many systems not being utilized.

I have been working with the systemd boot loader over the last several days. During this time I have reached some conclusions about it. I should note that my previous boot loader experience has been with lilo and grub (mainly grub) for the most part.

My Opinion

Systemd boot is not flashy, but it is fast. I will give it that. I have not had the chance to test it in a multi boot system yet. It is also a lot less code than some of the other boot loaders. My issue, like before, is that there is no choice about installing the boot loader if using systemd.

Coming from grub, it took me some time to understand how the boot loader and its configuration related to the system. And I have to say that most of the documentation I read was somewhat confusing. It basically took a bit of experimentation to get it to work. But once I got it working, the various document sources made a good deal more sense to me.

Unlike other boot loaders, systemd boot only works with UEFI (Unified Extensible Firmware Interface). This may or may not be an issue for some. It has been my experience that I am seeing less and less MBR (Master Boot Record) legacy boot systems out there, and correspondingly more UEFI systems. So this is probably not an issue for most users.

From my current understanding, I am not thrilled with how the EFI sector is mounted to the boot directory. But this may be because I have not done much testing with alternate mountings and layouts.

High Level Overview

To really understand how the systemd boot loader works, we need to understand first how UEFI boots a system, and second how the boot directory is laid out.

At a very high level, the firmware on your system board looks for any drives with an efi system partition. Once it finds one. It looks in the partition for a boot loader to run.

The default boot loader is bootx64.efi. However since we installed systemd, it will install and use the systemd-bootx64.efi boot loader, You can set a boot loader/boot order with efibootmgr on Linux systems, if installed.

The sytemd-bootx64.efi boot loader will read some configuration files which tell it where to find and run the Linux kernel/initramfs, which gets the whole system up and running.

Boot Directory

Now that we understand the boot process from a high level, we can look at the layout of the boot directory.

/boot directory structure

Under the root file system we will find the directory called /boot. The boot directory in our case should be mounted to the efi system partition (keep this in mind when creating/installing Arch). Within the boot directory is the EFI directory. This is where the boot loaders live. Since we are using systemd, we will focus on the systemd entries only.

Within the EFI directory, you will find the systmed directory that contains the systemd boot loader (systemd.boot64.efi, assuming 64 bit architecture).

The systemd boot loader will look for configuration files. Within the /boot/loader directory we will find the loader.conf file, which should already exist. This file provides basic instructions for how the boot loader will operate.

Within the /boot/loader/entries directory we will create (they do not exist by default) and store the system configuration files. There can be multiple configuration files depending on setup and need. In our case, since we are booting into a single instance of Arch, using the default kernel, there is only one file, arch.conf. Multiple configuration files would be shown as a list on the boot loader screen with one set as default.

Configuration of Systemd Boot Loader

The first file we want to look at is loader.conf. This file should already exist with some generic entries. We will modify it for our use. So fire up your favorite text editor (donโ€™t forget that you need admin access โ€“ aka sudo).

# My SystemD loader file

default		arch*
timeout		3
editor		0
console-mode	keep

I have set the default to Arch*, so any config file starting with โ€œArchโ€ should be shown as the default entry on the boot loader screen.

Setting the timeout to three means the boot menu will be displayed for three seconds by default. If set to 0 the boot menu will not be shown.

Setting editor to zero disables the boot menu editor. In theory you can make changes to the boot menu on the fly, have not tried it yet.

Setting console-mode to keep will use the default mode set by firmware.

Next we want to go into the entries directory and create a file called arch.conf, which will contain our configuration for booting into Arch when it is selected.

# Arch linux Boot Up File

title	Arch Linux
linux	/vmlinuz-linux
initrd	/initramfs-linux.img
options root=PARTUUID=3b99d2a8-330e-43cf-95df-4a43eaabac62 rw

The title is what will appear in the boot menu.

Linux and initrd need to point to your kernel and initramfs drive (that thing that gets updated sometimes when you install software). These files should be located in the /boot folder. Note that it is possible to have multiple of each file type (for example you might have a bleeding edge kernel for testing and a long term support kernel for fallback).

Under options we need to set our root partition. I have been using the Partition UUID which I get with the blkid command. I usually use this in conjunction with grep to output my root identification (sda3 in my case) and redirect it to append to my arch.conf file. Then I go in and clean it up with a text editor.

blkid | grep sda3 >> arch.conf

Check the man pages for the various ways to identify your root partition.

Reboot

Before rebooting you will probably want to disable any other boot loaders that are installed. In my case this is a clean install, so no other boot loaders to worry about.

Once we reboot, the systemd boot menu should show up, and we should be able to start our computer.

Conclusion

There it is, my take on systemd boot. I am hoping my explanation and overview makes sense, and that it helps people who are trying to use it.

next time around I want to discuss systemd networking.

SystemD Leviathan Part 1: Overview

SystemD Leviathan Part 2: Service Units

SystemD Leviathan Part 3: Time Works

SystemD Leviathan Part4: Boot Loader

SystemD Leviathan Part 5: Networking

Add New Comment

Your email address will not be published. Required fields are marked *