I freshly installed Fedora 39 Worsktation Edition on my second SSD.
I have a Dual boot with Windows 11.
I kept my WIndows 11 installation on the other SSD to play competitive gaming such as CS:GO.
And the face-it anticheat requires secure boot to run.
HAve to go to the UEFI settings to re-enable the secure boot everytime is such an inconvenience.
I switch a lot trough my operating systems.
I went through a lot of discussions and read a lots about the secure boot implementation, shim and stuff related.
I read lots of comments saying that Fedora is secure-boot compatible.
Unfortunately when i boot with secure boot enabled, grub appears, i choose fedora and … Black Screen.
Maybe it is driver-related ? My GPU is a Nvidia RTX 3070. Drivers infos below :
Despite my readings and search, i’m a little lost.
When i go to the UEFI Settings i only have two level of secure boot on my mobo : disable or enabled. No “Allow third party key” or stuff like that which i guess will be the solution !
Or maybe i have to change some grub parameters ?
I have to flash my motherboard with some key signatures to be trusted by Fedora at boot ?
You do not need to run fedora with secure boot disabled. Enabling it would avoid the repeated switching mode within bios.
Before enabling secure boot again first follow the steps detailed in /usr/share/doc/akmods/README.secureboot.
Once that is done then replace the unsigned driver with one that has been signed and it should work for you.
sudo akmods --force --rebuild to build the new (signed) driver
followed by a reboot. With this reboot enable secure boot and the drivers should still be loaded and operate.
I finally follow the a /usr/share/doc/akmods/README.secureboot instriuctions today.
Its was quick and easy to follow.
I think that if you use the key that was created by akmod when akmod first ran that you do not need to rebuild any driver as they where already signed by the default key.
Only if you create a new key, that is an optional step, would you have to rebuild the driver to have it signed by the new key.
Unfortunately if the driver was installed before performing the steps in that file, the currently installed driver will not be signed because the key has not yet been created by the kmodgenca command. The key must be created before akmods can sign the driver and that is not done by default.
This means you will have to remove the unsigned driver for the current kernel and recreate it in order for that module to be signed. This is why I showed the steps above.
You are 100% correct if the steps in the file /usr/share/doc/akmods/README.secureboot are completed before installing the nvidia driver.
I checked and the key existed without me running any manual commands.
I have an external SSD that I am using to test plasma 6 plus nvidia.
I will double check what is setup in it.
I was surpised that the keys existed and thats why I investigated.
I suspect that may well be important to force the keys to be created if you do not reboot between installing akmods and building the nvidia driver.
At boot the service akmods.service is run which will trigger the target akmods-keygen.target which in turn triggers akmods-keygen@.service.
The akmods-keygen@.service runs the command to generate the key unless a key already exists. This service is also run when installing a new kernel triggered from akmods@.service.
I noticed this when updating the VirtualBox modules for several years, and the module turns out to be already signed even when I didn’t do anything for this to happen.
I just checked according to what both @barryascott & @vekruse said with a new clean installed F39 (fully updated) system and tested to see what happens. Initially akmods was not installed.
I rebooted after the update then rebooted again.
Now I installed akmods.
Checking showed the doc I had previously mentioned at /usr/share/doc/akmods/README.secureboot was now installed and available.
I also checked /etc/pki/akmods/certs/ and /etc/pki/akmods/private/ were there but empty.
I now rebooted, and the keys were now available in both /etc/pki/akmods/certs/ and /etc/pki/akmods/private/.
It seems now that the akmods.service does create the keys if they are not available already at boot time.
However, that still does not manage the issue of the requirement to use akmods and rebuild the modules that were unsigned before akmods was able to create the keys.
It also does not negate the requirement to use mokutil and import the key into the bios for use by secure boot. The only part of the instructions in the README that might be unnecessary after a reboot is the use of the kmodgenca command.
I agree. If the installer were to first generate the key and run the mokutil command, then compile the drivers and install the normal kmod-* package; the new drivers would already be signed. The only required step for the user then would be to actually import the key into the bios during the reboot.
If secure boot is disabled there would be no difference for the user and if secure boot is enabled then the driver still could be automatically loaded since it would be signed when initially installed.
Be careful when using mokutil because in many cases (like mine) the required file /boot/efi/EFI/BOOT/mmx64.efi does not exist by default. That will cause a catastrophic failure during boot:
Failed to open \EFI\BOOT\mmx64.efi - Not Found
Failed to load image \EFI\BOOT\mmx64.efi: Not Found
Failed to start MokManager: Not Found
import_mok_state() failed : Not Found
In my case, this happened to 20 fedora desktop machines (Fedora 38). Interestingly, you can’t recover from this situation because boot stops there and automatically powers down the system.
Eventually, I had to boot a live ISO image with AlmaLinux, access the /boot/efi partition and copy the mms64.efi file from:
/boot/efi/EFI/fedora/mmx64.efi
to
/boot/efi/EFI/BOOT.
I hope this is helpful to others facing the same situation.
That would only happen if you system boots the /boot/efi/EFI/BOOT/BOOTX64.EFI instead of /boot/efi/EFI/fedora/shimx64.efi. Supposedly, booting the BOOTX64.EFI would run the fbx64.efi which should install a new entry into the UEFI boot menu using the information in the file /boot/efi/EFI/fedora/BOOTX64.CSV. For some UEFI implementations that could lead to running out of space in the UEFI memory.
@vekruse In my case it happens 100% all the time on all my machines. I just tried this on 20 fedora systems and all of them had this problem. Even tried two DELL laptops with the same bad result.
@hamrheadcorvette I know the rpm package is installed (systemd-boot-unsigned-253.14-1.fc38.x86_64) but that is all.
