[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

@BS86
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.

2 Likes

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”