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.
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.
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?
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.
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.
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
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
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?
