(Fedora 35) NVIDIA Kernel Module Missing. Falling Back to Nouveau


I’ve been banging my head against this issue for the last several hours and can’t find a solution. I followed The RPM Fusion Guide, and the installation went through but doesn’t work when I try to boot. I have also tried using t0xic0der’s nvidia-auto-installer script but had the same outcome. I’ve tried several troubleshooting threads including this.

For some background, I am running a brand new install of Fedora 35 on a PC with an ASUS Z97I PLUS motherboard, and an NVIDIA Titan Black GPU. This motherboard seems to be kind of weird about Secure Boot, but I managed to get it to at least say that it is disabled by following the advice in this thread (Deleting the Platform Key and disabling Fast Boot). Even after trying all of this, I am still getting the “NVIDIA Kernel Module Missing. Falling Back to Nouveau” message when I boot, and I am getting very poor GPU performance. I’ve tried basically everything I can think of, including multiple reinstalls of the driver and I still can’t figure it out. Does anyone have more ideas?

I’m not sure what documentation would be helpful here, so let me know if there is anything more I should include.

You can blacklist nouveau as described here:

I had to install the nvidia driver, today actually, by dropping the x session, running the installer I downloaded from nvidia, then starting x again. After that I blacklisted nouveau.

To get nvidia working I did the following:
Download your driver from nvidia -Download Drivers | NVIDIA
sudo init 3 - this kills the x server
cd /<.run file location> - navigate to the .run file
chmod 744 <filename> - enable execution
sudo ./<filename> run the installer

Follow the prompts from there, that worked for me.

Then, sudo init 5 - this restarts the x session.

Test with inxi -G to see which drivers are running on which devices. Highly recommend the inxi package actually.

This worked for me, but I am on much different hardware than you, so YMMV.

If you followed RPM Fusion instructions and got “Module missing”, then your UEFI firmware don’t trust the new OS is what my understanding. By default, it should disable Nouveau if you install Proprietary drivers. Check again in BIOS. Often time you have to add a BIOS Supervisor password to be able to disable Secureboot in newer Motherboards.

Also deleting Platform keys is not needed if you disabled the Secureboot.
and Disabling Fastboot is only to help the issues you get when Accessing Windows Partitions in Linux.

So check your BIOS Security & Boot Options thoroughly. Secureboot is not yet disabled.

I don’t think this would change anything in my case. My issue is with the Fedora Kernel not trusting the Nvidia module.

EDIT: This worked, but it’s kind of a sub-optimal solution as it needs to be redone for every kernel update

I tried adding adding a supervisor password as well, but unfortunately that didn’t change anything. The secure boot option is still grayed out, and the only way to get it to say “disabled” is by deleting the secureboot keys, although this still doesn’t fix the issue. I may just have to try calling ASUS and seeing if they have any insight.

1 Like

Try NVidia site … driver 470.86 released 10 november for Geforce GTX Titan Black with instruction for installing on Linux. A lot of fuss and puff but NVidia uses closed source proprietary software on closed source proprietary hardware. It’s just a question of choice but being latest and greatest, not sure that Nouveau drivers have catched on or Wayland is supported …

Either you have to disable Secure boot or Sign the kernel module yourself. But the problem with signing kernel by yourself is that whenever you update the Linux Kernel, you will have to manually sign and rebuild the module for each update and it can be annoying to do.

Assuming this is your BIOS it doesn’t seem like there is a way to turn off the Secureboot so may be try changing it to Other OS if that helps ( but I’m sure you probably would’ve tried that too ).

In my experience, and with many similar issues seen on this forum, it is 100% necessary with fedora 35 to disable secure boot since the fedora kernel now is actively blocking unsigned kernel modules from loading when secure boot is enabled.

Fast boot is not part of that, although fast boot can prevent access to the bios. Secure boot is likely under the security tab in the uefi firmware (although it varies by manufacturer and the firmware in use).

Also, the 470.86 driver is available from rpmfusion as is the 495.44 driver. The 495.44 driver is only for F35+ and its main advancement that I am aware of is the improved compatibility with wayland. Installing the nvidia drivers from rpmfusion is my standard procedure.

The problem in this case seems to be that my motherboard, while it claims that Secure Boot is off after deleting secure boot keys (which is the suggested procedure according to ASUS) does not actually have it off, or there is some other confounding variable that is making things not work. Installing using the .run file from NVIDIA works, but unfortunately unless I wanted to manually sign the kernel module every time (which defeats the purpose of getting it from the repo anyway) there seems to be no way to make my motherboard play nice with the RPM NVIDIA driver.

Removing the secure boot keys does not disable secure boot. There is a setting explicitly to disable it.

Look into the bios setting a bit more. The setting is usually very close to where you removed the keys.

That’s just not the case with this motherboard. I have dug through every single setting, as well as contacting ASUS and that is the only way to get it to say disabled, as well as what the company recommends.

Something going wrong … Asus is a fully compliant OEM and secure boot is an EFI feature launched by Intel to update BIOS standards that forbids accessing OS not previously installed with certificate being digital blob security key targeting global installation and not details like kernel modules. The question concerns incompatible software stack between RpmFusion and Fedora going further as including RHEL, Oracle Linux and others.
Definitely, a ‘watercooled’ topic is necessary …