Moving from GRUB to systemd boot

On my system, the /usr/lib/systemd/boot/efi is provided by package
systemd-boot-unsigned, I do not know at which stage it was installed.
It contains the file systemd-bootx64.efi which ends up in /efi/EFI/systemd/systemd-bootx64.efi, which is finally the bootmanager started by BIOS. I do not know what happens when using signed BIOS.

Sorry, the dots in the kernel-install command were just the placeholder for the actual version on your system, /boot/vmlinuz… should be the name of the existing kernel for your version and not literal.
On my system, uname -r shows 6.3.3-200.fc38.x86_64, so the command is
kernel-install add `uname -r` /boot/vmlinuz-6.3.3.200.fc38.x86_64
(In fact, /boot/vmlinuz-`uname -r` is also possible and more consistent)

bootctl should show no red x, this indicates that you did not use systemd-boot.

Output on working system:

https://paste.centos.org/view/7777258d

1 Like

You can get the exact command to use by running

rpm -q --scripts kernel-core |grep add

On fedora, the vmlinuz is found in /lib/modules/$(uname -r)/ from where kernel-install will copy it to wherever it is needed.

1 Like

I always use systemd-boot on Fedora. For me, it is much easier to mount the ESP at /efi. I don’t see much value in mounting it at /boot. Since Fedora uses kernel-install there is no dependency on /boot.

This is what I have:

[fedora@fedora ~]$ sudo tree /boot
/boot
β”œβ”€β”€ config-6.2.9-300.fc38.x86_64
β”œβ”€β”€ efi
β”‚   β”œβ”€β”€ 954daf6199ea4136aa3342a75044cc9b
β”‚   β”œβ”€β”€ EFI
β”‚   β”‚   β”œβ”€β”€ BOOT
β”‚   β”‚   β”‚   β”œβ”€β”€ BOOTIA32.EFI
β”‚   β”‚   β”‚   β”œβ”€β”€ BOOTX64.EFI
β”‚   β”‚   β”‚   β”œβ”€β”€ fbia32.efi
β”‚   β”‚   β”‚   └── fbx64.efi
β”‚   β”‚   β”œβ”€β”€ fedora
β”‚   β”‚   β”‚   β”œβ”€β”€ BOOTIA32.CSV
β”‚   β”‚   β”‚   β”œβ”€β”€ BOOTX64.CSV
β”‚   β”‚   β”‚   β”œβ”€β”€ gcdia32.efi
β”‚   β”‚   β”‚   β”œβ”€β”€ gcdx64.efi
β”‚   β”‚   β”‚   β”œβ”€β”€ grub.cfg
β”‚   β”‚   β”‚   β”œβ”€β”€ grubia32.efi
β”‚   β”‚   β”‚   β”œβ”€β”€ grubx64.efi
β”‚   β”‚   β”‚   β”œβ”€β”€ mmia32.efi
β”‚   β”‚   β”‚   β”œβ”€β”€ mmx64.efi
β”‚   β”‚   β”‚   β”œβ”€β”€ shim.efi
β”‚   β”‚   β”‚   β”œβ”€β”€ shimia32.efi
β”‚   β”‚   β”‚   └── shimx64.efi
β”‚   β”‚   β”œβ”€β”€ Linux
β”‚   β”‚   └── systemd
β”‚   β”‚       └── systemd-bootx64.efi
β”‚   β”œβ”€β”€ loader
β”‚   β”‚   β”œβ”€β”€ entries
β”‚   β”‚   β”œβ”€β”€ entries.srel
β”‚   β”‚   β”œβ”€β”€ loader.conf
β”‚   β”‚   └── random-seed
β”‚   β”œβ”€β”€ mach_kernel
β”‚   └── System
β”‚       └── Library
β”‚           └── CoreServices
β”‚               └── SystemVersion.plist
β”œβ”€β”€ grub2
β”‚   β”œβ”€β”€ fonts
β”‚   β”‚   └── unicode.pf2
β”‚   β”œβ”€β”€ grub.cfg
β”‚   └── grubenv
β”œβ”€β”€ initramfs-0-rescue-954daf6199ea4136aa3342a75044cc9b.img
β”œβ”€β”€ initramfs-6.2.9-300.fc38.x86_64.img
β”œβ”€β”€ loader
β”‚   └── entries
β”‚       β”œβ”€β”€ 954daf6199ea4136aa3342a75044cc9b-0-rescue.conf
β”‚       β”œβ”€β”€ 954daf6199ea4136aa3342a75044cc9b-6.2.9-300.fc38.x86_64.conf
β”‚       └── 954daf6199ea4136aa3342a75044cc9b-uname -r.conf
β”œβ”€β”€ lost+found
β”œβ”€β”€ symvers-6.2.9-300.fc38.x86_64.gz -> /lib/modules/6.2.9-300.fc38.x86_64/symvers.gz
β”œβ”€β”€ System.map-6.2.9-300.fc38.x86_64
β”œβ”€β”€ vmlinuz-0-rescue-954daf6199ea4136aa3342a75044cc9b
└── vmlinuz-6.2.9-300.fc38.x86_64

I read the replies and tried the following additions:

sudo dnf install systemd-boot-unsigned
sudo bootctl --make-entry-directory=yes --esp-path=/boot/efi install
Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/efi/EFI/systemd/systemd-bootx64.efi".
Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/efi/EFI/BOOT/BOOTX64.EFI".
Random seed file /boot/efi/loader/random-seed successfully refreshed (32 bytes).
Created EFI boot entry "Linux Boot Manager".
[fedora@fedora ~]$ rpm -q --scripts kernel-core |grep add
/bin/kernel-install add 6.2.9-300.fc38.x86_64 /lib/modules/6.2.9-300.fc38.x86_64/vmlinuz || exit $?
[fedora@fedora ~]$ sudo kernel-install add $(uname -r) /lib/modules/$(uname -r)/vmlinuz
[fedora@fedora ~]$ sudo bootctl
System:
      Firmware: n/a (n/a)
 Firmware Arch: x64
   Secure Boot: enabled (user)
  TPM2 Support: no
  Boot into FW: supported

Should I try to disable secure boot? Again, a series of red x.

Output doesn’t look like that yet…

I still get an error message on host start up about an β€œoverflow detected” in grub, so actually, it might be good for me to get systemd-boot right. Some of those error messages are very obscure and its hard to find a solution. I do have a password on grub2 but never get asked for it. And then an error message read that the boot partition is running out of memory. So the information being provided here about how exactly to configure boot partitions is helpful.

Probably. Last I heard, the systemd bootloader isn’t signed with the cert that comes pre-installed by the hardware vendors. I guess you could add your own cert to the system firmware and then sign the bootloader yourself. But if you are just trying to get the booting to work, the first thing to try would be to get it working without secure boot.

@vekruse Thanks, that’s the best way to find the correct command, especially because the copy in /boot only exists if a grub based install has been done before.

@dalto It looks to me that the ESP for grub MUST be /boot/efi in order to match the file locations in the grub rpms, and for systemd-boot it should be /efi; /boot is superfluous after systemd-boot has been activated.

There is one situation where a /boot partition is used with systemd-boot: if Windows gives you an EFI partition which is far too small, a VFAT formatted boot partition with special label can provide additional space.

So I noticed that the third comment (@vekruse) stated that disabling secure boot is β€œstep zero” and I tried
sudo mokutil --disable-validation
but when I check
sudo mokutil --sb-state
Secureboot enabled
Secureboot validation is disabled in shim
sudo bootctl
Secure Boot: enabled (user)
And there still is a series of red x β€œFeatures” that doesn’t look like systemd boot was successful. Is there more to do to disable sb than disabling validation in shim?

Can someone explain what is going on with the boot tree? It says there is a systemd-boot but grub is still selected?

Then this part of the tree shows that boot is in EFI like @h.janssen suggested, right?

Secure boot is usually turned on or off using the device’s BIOS configuration menu (press the F2 key while booting).

In the case of coreboot, you have to do that with the configurator. F2 works for Legacy BIOS. I am wondering about turning SB off in the VM because I am testing in a VM before trying systemd boot on bare metal. Good thing too.

Do you know what SecureBoot is securing? It’s not just a matter of hard drives being swapped out to different platforms? Boot data can be changed remotely so the CPU and TPM should make sure that internet exposed drives have not been maliciously modified?

That sounds about right. It β€œsecures” files by attaching a checksum signature to them. In a way I guess it is not unlike this slightly older variation on the concept. :slight_smile:

1 Like

WIth sd-boot, you don’t have the shim anymore, which also means you don’t have the mok either.

To disable secure boot in qemu/kvm:

At the grub2 prompt select UEFI Firmware Settings. Then

Device Manager β†’ Secure Boot Configuration β†’ Current Secure Boot State

Then save and quit.

For bare hardware, search Google for for xample how to disable secure boot or something similar.

1 Like

Yes, that is cool. I find that there are a lot of big questions raised even by technical, pragmatic operations. What is identity and authentication all about? What are the tradeoffs between security and privacy? Is anonymity or rigid designation a stronger defense? All these topics have a long history in our technics and engineering designs.

When I disabled secure boot, unXed the β€œ[ X ]” to disable sd and then saved with F10, the VM will not boot the OS but keeps returning to the firmware settings with a countdown. There doesn’t seem to be any option available from the UEFI boot menu. Also, Fedora (uname -r) showed up as a boot option but that doesn’t boot. I think there is a command I still have to enter in terminal that initializes the boot process to select systemd over grub.

The firmware does not have a countdown, and it is blue. So you would either have the grub2 menu or the sd-boot menu. The former is displayed with a frame around the menu, and the latter has no frame.

When running bootctl --install, the firmware will be set up to boot to the sd-boot.

The procedure from https://kowalski7cc.xyz/blog/systemd-boot-fedora-32/ did show you the steps.

disable secure boot in the firmware

sudo dnf install systemd-boot-unsigned

sudo mkdir /efi
sudo cp /etc/fstab /etc/fstab.bak # (Make a backup first if you are unsure)
sudo vi /etc/fstab  # Change the mountpoint from /boot/efi to /efi.  Can also use nano to edit.
sudo umount /boot/efi
sudo mount /efi
sudo mkdir /efi/$(cat /etc/machine-id)
sudo bootctl install
sudo kernel-install add $(uname -r) /lib/modules/$(uname -r)/vmlinuz
1 Like

What you see is sd-boot with firmware as only boot option. You really need a kernel on the efi partition below /efi/loader/entries and /efi/machineid/kernelversion/vmlinuz + associated initrd, then it will work.

On my system, I’ve secure boot on, it starts systemd-boot with permission denied and falls back to grub. So grub secure boot works out of the box, systemd-boot does not. For the rest, I only find utterly complex procedures which may brick your motherbord if bare metal, and a β€œsbctl” which I cannot find in Fedora, so this is not simple. The best I found which gives explanation about the whole process is
https://sysguides.com/fedora-uefi-secure-boot-with-custom-keys/
I’ve to study it carefully, just wondering now whether it is fundamentally possible to sign a binary yourself for use with secure boot without having secrets from redhat or microsoft. If not, you have to change the PK with one from yourself and then it starts to be very complicated…

Works!!!
You can have systemd-boot in secure mode, if you follow the nice guide in the link above, with only Fedora tools. But it will completely change your BIOS and rule out Windows (and redhat) secure boot. So on bare metal BIOS, there are risks.

First, systemd-boot should work without secure boot!

You can skip the removal of signatures on shimx64.efi, and sign systemd-bootx64.efi. This bootmanager is unsigned and will never work without signature with secure boot switched on.
In contrast to what the tutorial tells, I had to add a signature on the kernel.
initrd and kernel modules are not touched.
Of course, every following update will require signing of systemd-boot and/or kernel.

For a VM, I would look into the signed uki-virt kernel which can be launched from UEFI directly.

System:
      Firmware: UEFI 2.70 (EDK II 1.00)
 Firmware Arch: x64
   Secure Boot: enabled (user)
  TPM2 Support: no
  Boot into FW: supported

Current Boot Loader:
      Product: systemd-boot 253-6.fc38
     Features: βœ“ Boot counting
               βœ“ Menu timeout control
               βœ“ One-shot menu timeout control
               βœ“ Default entry control
               βœ“ One-shot entry control
               βœ“ Support for XBOOTLDR partition
               βœ“ Support for passing random seed to OS
               βœ“ Load drop-in drivers
               βœ“ Support Type #1 sort-key field
               βœ“ Support @saved pseudo-entry
               βœ“ Support Type #1 devicetree field
               βœ“ Boot loader sets ESP information
          ESP: /dev/disk/by-partuuid/2f9beffb-3bab-b244-aa5f-78bed1d50ca1
         File: └─/EFI/systemd/systemd-bootx64.efi
1 Like

Got sudo bootctl Product: systemd-boot 253.4-1.fc38

  • Only addition to reply #34 is systemctl daemon-reload after editing /etc/fstab
  • Systemd boot works after secure boot is disabled at the UEFI Firmware menu but apparently secure boot can work with systemd boot after signing.

Thanks everyone!

Before doing that you need to use the discoverable partition features as described in https://uapi-group.org/specifications/specs/discoverable_partitions_specification/.
The reason is that the UKI image does not know which device contains your root file system.

Alternatively, you can build your own UKI with your current kernel command line (/etc/kernel/cmdline) baked in.

Thanks, @vekruse , for this valuable tip, I already found it somewhere staring at a console screen showing a stopping boot process asking myself where I have to define the OS root…

For Fedora, one has to add in case of btrfs that the subvolume containing the root directory should be set as the default one, and not subvolid=5.

Is it not the advantage of the Fedora provided UKI kernel that it runs out of the box under secure boot with the Fedora keys, and that you do not need to modify the BIOS?

Can someone tell me what I can do to remove GRUB2 from boot since I have systemd boot now? Does it even matter? If systemd boots, GRUB is now ignored? I get an error message on start up about GRUB overflow and think this message would go away if GRUB was removed. Additionally, I get a message that there is not much space remaining in /boot, I think because I have to remove multiple initramfs-rescues. What should I do about that? Thanks.

1 Like