A few weeks ago, I managed to finally enable Secure Boot on my Acer Laptop. However, soon after I realized that my then fan control method (NBFC-Linux) was using a kernel module (acpi_ec) to control the fans, and thus meant that my fans would not work at all because whatever kernel module that was isn’t being loaded when Secure Boot is enabled. And so for the past few weeks, I had to keep Secure Boot disabled once again.
Recently though, I have since switched to using Div Acer Management Max, which uses these linuwu-sense drivers and thought I’d try to get these working with Secure Boot. I found this repo which included a script to automatically sign it and it did work! However, I was worried that relying on only this would mean I have to do this every time there was a kernel update, so I did some more research and found this discussion about installing a kernel module on a secure boot enabled Fedora. And so, I followed the guide from top to bottom and it did seem to work! And it just so happened there was a kernel update just as I finished it (6.17.10-300), so I decided to try and see if it’ll survive it. Unfortunately, it did not work. In fact, I can’t even boot into the new kernel, as systemd-load-modules fails to load regardless of my Secure Boot setting right as it starts to build the Nvidia drivers, so I had to use the previous for now.
With this, I basically have two questions:
How would I fix not being able to boot into the new kernel?
How do I actually properly add a new Kernel Module then while still being able to support secure boot?
It sounds like you may have interrupted the build of the nvidia drivers.
Try sudo akmods --rebuild --force --kernels 6.17.10-300.fc43.x86_64 to ensure all akmod modules have been rebuilt for the new kernel then reboot.
The new module you are trying to use appears that it will require a rebuild with every kernel update, though the steps in the repo link you provided appear to need nothing more than the final command make install (in the build directory & after booting into the newer kernel) to perform the upgrade.
The steps do not appear to use dkms with what you provided so the discussion topic linked would not apply and manual updates would probably be necessary.
I do note though that it appears to build the module that is then stored in the firmware area and is available to auto-load from there. That means that the only thing that may overwrite it would be the monthly update to system firmware and rebuilding could be scheduled to coincide with those updates (probably not dependent upon kernel updates).
Thank you, but unfortunately, that akmods command did not seem to help, and I am still faced with the same error that the systemd-load-modules.service can’t start. I wonder if I need to remove the module I added with modprobe first? Or maybe there’s still something else.
As for the second point, I was afraid of that. Though Vladislav’s answer is worth giving a shot. I should probably wait until I can resolve the problem with the new kernel before I attempt this. I believe I saw something like this during my research, but there were some syntax on it that I just wasn’t familiar with, so I refrained from doing so. I’ll be sure to give this one a try though once I can boot into the new kernel.
An update on the newer kernel; Somehow, removing the quiet kernel parameter allowed me to go through? This also removed the error from showing up after the akmods nvidia building notice, replaced with some other status display. I checked JournalD afterwards, and it most likely stemmed from the fact that the linuwu_sense drivers (and the acer_wmi drivers it replaces) was not present at all. I have attached the JournalD logs below.
I will now try to remove my previous progress by running dkms remove (or unbuild?), removing the linuwu_sense repo from usr/src/ and then running Vladislav’s commands.
I have now performed these commands for the most part, and the drivers are working once again. I’ll have to wait and see if it works for the next update though. I do have to note I did not go through the mok generation, as it complained that it was already enrolled, but the driver still loaded successfully in Secure Boot regardless.
Additionally, going through this, this did seem very similar to the discussion I linked, but I set the configuration file differently then. I provided a fake package version as none was specified, both package and module name was the same using an underscore instead of a dash specifically for the package name, and the destination was set to /kernel instead of /extra. Hopefully the configurations you have provided here prove to survive the next kernel update.
I’ll be sure to update here when the next kernel update comes. Thanks again to both of you for you tremendous help!
Note that once the mok key is created it will continue to be available and used unless the user explicitly forces creation of a new key. Thus recreating it is not required in almost all cases. (If a new key is created then the new key would also need to be imported into the bios.)
