I do not use secure boot and when I install a new kernel, building the new drivers (both for Nvidia and VirtualBox) fails. I think the corresponding errors are:
Fixes the issue. As I do not use Secure boot, no signing is actually required. However, I am using sd-boot (installed via netinstall). Why is the signing still taking place?
Also, the experience of this is rather suboptimal. When splash is enabled, the Fedora logo just spins for over a minute before giving up and proceeding. Pressing escape to get rid of the splash does not work. Without the splash, there is just underscore blinking for the same amount of time. I was really left in the dark and first forced-turned off my computer thinking it just got stuck. No idea where to report such a UI bug though.
@felagund
If you are using rawhide there may be issues that cannot be solved here since that is the development version of fedora and users must be aware that there are often things that may break. The only fixes are by directly contacting the developers since those issues are caused by changes in apps as the process moves toward the next release version.
When you remove those keys, the next boot will recreate them as an automatic function of akmods and the kmodgenca command.
The errors you report seem to be from ssl and have nothing to do with the key itself.
Signing of locally compiled kernel modules is automatic when akmods creates those modules. It is necessary when secure boot is enabled and harmless when secure boot is disabled.
The only other nonstandard thing is that my laptop battery ran to zero twice, so the inner computer clock got reset (I booted up and it was reporting nonsensical time until NTP kicked in, which happens quite fast actually). Could it be that SSL somehow checks the time and smells something fishy? It has happened twice already. To try to reproduce it I need to wait for a new kernel to come to updates.
Unless the signing fails, in which case the modules are thrown away even if they compiled just fine.
Well, a new kernel is here. It still fails. Time on my system is correct, so that will not be the problem.
First, when I try to run
$sudo akmods --force
Could not find files needed to compile modules for /boot/efi//3df672eef9054350b62cccb2eae56a38/7.0.12-201.fc44.x86_64/linux
Are the development files for kernel /boot/efi//3df672eef9054350b62cccb2eae56a38/7.0.12-201.fc44.x86_64/linux or the appropriate kernel-devel package installed?
However, unless I remove the keys, it fails. It very much feels like a bug, only I am not sure what against I should report it, against akmods? I can imagine there is something weird on my system, but apart from installing sdboot, I do not think I did anything too weird to it.
What am I looking for? I checked your link, but this is a freshly installed Fedora 44, so I think it does not apply (and I only started to use Fedora with Fedora 42).
My hypothesis is that if I removed or renamed that directory, my system would become unbootable. Still, since systemd-boot is supported (you can install it via net-install), this should not be happening. However, I seriously doubt I am the only one using both systemd-boot and having NVidia, so there must be something else that is causing this.
For systemd-boot, leave those as they are. The lack of any grub components would be typical if you select sdboot during install from the netinstall image.
You mentioned something about the RTC clock. Is that now fixed or is that an issue? Do you run your updates using offline update? Doing so could be problematic if the clock isn’t set correctly before the actual update is run.
You also meantioned that removing the keys fixed the problem. So is the problem fixed or not?
When a new kernel is installed via a DNF update, the keys get regenerated, so I need to remove them again. Even when they are removed, sudo akmods complains about the source not being installed.
Hm, so I ran sudo /usr/sbin/kmodgenca -a and it seems to fix the compilation problem. Which is kind of weird, as, at least to my understanding, that is what is run when the keys are not present when installing a new kernel. Now I have:
And sudo akmods --force --rebuild --kernels 7.1.3-201.fc44.x86_64 now runs fine.
I still get:
sudo akmods
Could not find files needed to compile modules for /boot/efi//3df672eef9054350b62cccb2eae56a38/7.1.3-201.fc44.x86_64/linux
Are the development files for kernel /boot/efi//3df672eef9054350b62cccb2eae56a38/7.1.3-201.fc44.x86_64/linux or the appropriate kernel-devel package installed?
Checking kmods exist for 7.1.3-201.fc44.x86_64 [ OK ]
It would appear that you have been removing the links /etc/pki/akmods/certs/public_key.der and /etc/pki/akmods/private/private_key.priv but have been failing to remove the actual key files those links point to.
I suggest that you remove all those files with sudo rm /etc/pki/akmods/certs/* and sudo rm /etc/pki/akmods/private/* then reboot. It should then show only the actual newly created key file and the new link to that file in each of those directories.
A kernel update has nothing to do with those keys. When those keys do not exist a reboot with akmods installed causes new keys to be generated. If they already exist they are not altered.
Yes, that happened and now I only have one key and sudo akmods suceeds. You must be right I was only removing the link. And it seems problematic that the size of the key from May 30 was zero. However, it is very unclear why it was failing with keys from June 15 and July 14–16. Maybe the link was wrongly being recreated to point to the key from May 30? Hard to say now.
As can be seen from your post above the links pointed to only the most recently created key file.
I cannot say why the extra files may have been the problem, but having a key file with no content certainly may have been the issue. Without knowing how akmods determines which key file to use it is hard to say. Potentially akmods may have been trying to use ALL the key files (not just the link) and having an empty file could then cause the issue seen.
the compile was already successful. So just having multiple keys and having and empty key in the directory was not a problem.
But that was after manually running sudo /usr/sbin/kmodgenca -a - maybe when it is run automatically at boot, it does something differently and it was linking to a different key? Who knows. If this happens again, I would investigate further, but for now I would let it be. Thanks for all the advice.