[Tutorial] Convert to systemd-boot

That is the machine ID.

No, that sequence will stay the same. It is safe to put that sequence in loader.conf.

The Arch wiki is using a manual approach where you hand create the conf files when you add or remove kernels.

We use an automated tool called kernel-install that is part of systemd itself. It automatically creates and deletes the conf files as they are needed and it manages the names.

The reason the names contain the machine ID is so that if you are booting multiple distros the entries can be differentiated.

1 Like

Your contribution has helped me a lot with my 2nd SSD

with Windows, after switching to system boot,

after switching to system boot.

Thank you very much

I recently reinstalled EOS on a laptop and noticed that systemd-boot seems to now be the default (i.e. pre-selected) option. My desktop is still using Grub so I started looking into this and found this thread.

At the top, in the update of 12/22/2022, it is stated that:

On the other hand, simplicity comes with limitations:

  • It only supports UEFI
  • It doesn’t have all the advanced features of grub
  • Your kernels must be kept inside your efi partition so it needs to be large enough to hold them all
  • Because of the above, booting directly from btrfs snapshots is not easily achieved

Now, my desktop uses UEFI and has a large EFI partition so the first and third bullet I’m not worried about. The other two I was hoping to get an update on:

  1. My root file system is BTRFS and I use snapper and grub-btrfs to make my snapshots bootable. Therefore the last bullet is an issue for me. Has any progress been made on that front? I can easily extend the size of my EFI partition as needed, but is it now feasible to have bootable snapshots with systemd?
  2. What “advanced features” of grub are still missing? Is it something superficial like “themes” or is there anything significant missing?

If you want to boot off of snapshots you should just use Grub.

There are users who are booting off of snapshots with systemd-boot by setting up custom tooling for it, like in this post for example: SystemD boot + secure boot + TPM2 unlocking + UKI + Dual boot (windows) + Dracut + BTRFS + LUKS2 + boot from Snapshots - #6 by Svartis. It’s obviously not as easy to set up as just installing a couple packages like it is with Grub.

If you want to you can set up a custom.cfg file with Grub to add custom settings, menu entries, scripts, etc which can extend and customize the bootloader’s behavior beyond what systemd-boot supports. Grub can be configured in kind of a modular way with the /etc/grub.d directory as well, for tying in scripts or other processes with the boot routine.

Grub can also chainload bootloaders; I’m not sure if systemd-boot supports that. There are also difference with how the two bootloaders handle encrypted setups or rescue mode (I’m not sure if systemd-boot has a dedicated rescue mode per se).

systemd-boot is in general a much leaner, simpler bootloader so does not have quite as many features available. Features are nice, but many people do not need all the features Grub offers. Plus Grub has a long and storied history of breaking when people do not properly handle its maintenance. :wink:

Still: if booting off of Btrfs snapshots is important to you I would recommend you just use Grub.

It isn’t really a feature gap, it is just a side effect of the way it works. Since the kernel and initrd are outside the snapshot, it causes a problem if you try to boot off a snapshot tied to an older kernel.

There are workarounds but they add more complexity than they are worth. If you want to boot off snapshots, just use grub.

Lot’s of things. Grub is a substantial piece of software. systemd-boot’s advantages are in it’s simplicity.

  • Theming
  • Grub supports submenus and fine grained control of the menus
  • Grub has built-in filesystem drivers
  • Grub can boot from multiple physical devices

systemd-boot can chainload. It is trivially easy to configure too.

Is there any actual use-case for grub’s rescue mode on an Arch-based distro?

I would agree it’s probably faster and easier to fix anything that can be fixed from Grub’s rescue environment in a chroot from the live environment instead, if that’s what you mean. I guess an actual use case would be if you have no USB stick handy?

I did not say it was a very excellent, highly useful feature–I only said it was a feature. :grin:

1 Like

This should work also in the future ```
wget -O - http://YOUR_SCRIPT.sh | bash

Just a note. That is extreamly bad practice to pipe downloaded script directly to bash. It is alway recommended to download it as a first step, inspect it and then run it.
Althout it may be from a trustworthy source you may never know if it contain something nasty inside.


I think openSUSE might be working on something like that for systemd-boot: sdbootutil
There was this long article a while ago: https://news.opensuse.org/2023/12/20/systemd-fde/ and they mentioned sdbootutil under the systemd-boot sub-heading in the text.

You are right I should have added the note “of course only do that if you know the source,and inspected the content”

Is it possible to directly install systemd-boot in chroot and don’t use grub at all ?
I tried a terminal install and afterwards booted the system with grub.
The conversion worked perfect bit just curious if it is possible to do a terminal install and don’t use grub at all

This tutorial was written for people who had old installs before the installer supported systemd-boot. Now you can directly install systemd-boot via the installer.

You can choose “No bootloader” if you don’t want to install grub and then install your own, yes.

thanks @dalto
I know i have the option “no bootloader” in the installation procedure.
What i actually mean is an installation directly from the iso terminal.

  • create partitions
  • make filesystems
  • make subvols
  • mount @
  • make dirs in /mnt
  • mount efi
  • mount subvols
  • do a pacstrap and genfstab
  • chroot
  • exit and reboot

I used to grub install in chroot however don’t want to use it but where does systemd-boot fit in ?

If you are installing EOS, you should add dracut to your pacstrap. Mount your EFI partition to /efi. The run bootctl install from the chroot. Next install kernel-install-for-dracut. Lastly, reinstall your kernel packages.

1 Like

did some testing in a fresh vm with your suggestions.

Ahh…I forgot one step.

Before installing kernel-install-for-dracut, you need to setup your kernel options in /etc/kernel/cmdline.

Your initrd line is probably wrong so it can’t find the root partition.

Thanks @dalto it worked.

this is in chroot


bootctl install
pacman -Sy --noconfirm kernel-install-for-dracut

set entries /etc/kernel/cmdline

echo "nvme_load=YES nowatchdog rw rootflags=subvol=/@" | sudo tee -a /etc/kernel/cmdline

Determine the UUID of the root filesystem

ROOT_UUID=$(blkid -s UUID -o value $ROOT_PARTITION)

Add the root UUID to /etc/kernel/cmdline using sed

sudo sed -i "s|subvol=/@|subvol=/@ root=UUID=$ROOT_UUID|" /etc/kernel/cmdline


set entries /efi/loader/loader.conf and adjust files in /efi/loader/entries *.conf

echo "default $machineid*" | sudo tee /efi/loader/loader.conf
echo "timeout 3" | sudo tee -a /efi/loader/loader.conf
echo "console-mode auto" | sudo tee -a /efi/loader/loader.conf
sed -i 's/quiet//g' /efi/loader/entries/*.conf
exit ...
umount -R /mnt;systemctl poweroff

Noticed that is my default eos install the entry rootflags=subvol=/@ UUID occured three times.
No big deal however.

Hopefully one day you write a fresh tutorial systemd-boot for a minimal eos.

Thanks for your advice

1 Like

These files get replaced every time a kernel updates.

You should make the changes in /etc/kernel/cmdline instead.

That was a bug in an older version of the installer. It won’t hurt anything to leave it but tou can fix it by removing the dups from /etc/kernel/cmdline.

1 Like