I would like to install Fedora 39 with systemd-boot and secureboot enabled on my Framework 13 AMD. However, I haven’t been successful yet. Since it is now possible to directly install Fedora 39 with systemd-boot rather than GRUB as the default bootloader, as described here. This method works and installs with systemd-boot as the bootloader, but after rebooting, secureboot was not enabled.
So, I went into the BIOS and set ‘Enforce Secure Boot’ to ‘enabled’. I also added the trust signature under ‘Select a UEFI file as trusted for execution’ and added “/EFI/systemd/systemd-bootx64.efi”.
However, after rebooting, I get the following screen:
You are trying to install Fedora with systemd-boot, correct? We have not tested against this as Fedora recommends GRUB and the page you linked to is very edge case and not likely to work out well.
All of that said and making sure you know this is strictly based as is with systemd-boot and completely unsupported by us, you could try Restore Secure Boot to Factory Settings (this again assumes that Fedora is the only OS installed).
So I’m mostly guessing, I don’t have secureboot running yet, but I want to try to get it working too soon. It it’s my first time fiddling with secureboot, so I don’t have a lot of experience yet, but I already read a lot about how it’s supposed to work.
So my guess is: After you enabling secureboot in the BIOS, systemd-boot detected, that secureboot is now enabled and booted in secureboot-mode where it requires all files it loads to be signed/trusted by the BIOS. As you only added the hash of the systemd-bootx64.efi in the BIOS, that loaded fine, but when it then tries to load the kernel (6.5.11-300.fc.x86_64/linux) that one is neither signed, nor trusted in the BIOS. So it’s not allowed to load it and it aborts the boot at this point.
As you probably don’t want to add the hash to each file that gets loaded to the BIOS manually, I would recommend that you create your own signing key and add that to the BIOS, and then you can simply just sign all the files. I don’t even know if manually adding the hash of the kernel to the BIOS would even work, or if that only works for which files the BIOS loads itself.
My preference over individual distro userspace cli one-stops is adding to the parameter directly and running the regen grub scripts - as this process is the same accros distros.
You can temporarily test by editing the grub menu entry from the grub shell by interupting it and editing it as a one-shot . Once you’ve proven it works editing /etc/default/grub will net
I used grubby in the past; but after hitting a couple of scenarios where it wasn’t actually updating entries consistently &| not doing indempotency properly (i.e adding args twice) gave up on it.
I tried this as well, trying to get away from the complexity of grub and put kernels into the efi partition instead of a separate /boot partition.
(However systemd peeps can’t help themselves and added a lot of complexity here as well. They make a big mess of the efi system partition with uuids that I don’t need.)
TL;DR is that I had to turn off secure boot for now (access denied), I don’t need it quite yet.
A few tips for the Fedora 39 systemd-boot install which was a big pain. I probably installed it from scratch 4 or 5 times:
I recommend using Ventoy for the flash drive, so much more flexible.
You need to use the Fedora “netinstall” iso or it will fail at boot-loader install at the end. (Regular isos don’t have the sdboot packages.)
Use the inst.sdboot install parameter as directed.
When you do netinstall with inst.sdboot there will be a conflict with Anaconda something or other and the Cinnamon desktop option and crash.
(I didn’t try other GUI options)
Instead pick “minimal install”.
Make sure to pick “Additional NetworkManager plugins” on the right side pane after minimal install or you won’t have working wifi after reboot. Which means text console only and no ability to install anything else. Unless you have wired ethernet.
If you did all that right on the first try, reboot to text console Fedora—with wifi.
nmcli can get you online.
Install favorite packages/desktop from dnf.
This will result in a mostly working system, but I still had some medium-sized issues: External monitor from DP-card not responding. Screen off after waking from sleep. Redshift not working.
Upgraded to 3.03 firmware, but it didn’t fix anything. Issues seemed to point to a video driver problem. After an hour or two of fruitless searching I realized the amd_gpu module was not loading, though other amd_ modules were. I tried to load the module manually but it responded only with “bad parameter”. Didn’t register at first but finally thought about kernel parameters.
Kernel parameters! Yes, I think “minimal install” aka text mode put “nomodeset” into the kernel parameters. I removed that at the sdboot menu and those issues were gone.
Then I removed nomodeset from ESP loader confs (I think) and /etc/kernel/cmdline to make sure it is not there for every boot and future installed kernels as well. Phew.
(Next issue is the frequent waking from sleep, think I saw that around here somewhere.)
