How to load nvidia driver with secure boot enabled on fedora 36


The rpmfusion site shows how to enable secure boot with fedora 36 and sign the nvidia driver so it properly loads.

What it fails to say is that the steps and commands given can only be done after fedora 36 is active and thus when upgrading from an earlier version of fedora the user is left with an unsigned driver at the time of upgrade and the following boot. The unsigned driver will not load with secure boot enabled as has been the case for all prior versions of fedora (35 and earlier)


For users with the nvidia driver already installed and doing an upgrade from fedora 35 or earlier, the nvidia driver will be upgraded as well and the drivers will be built for the new kernel before the user can follow the given steps to generate the key, import it into the BIOS, and sign the nvidia driver.

Related Issues


The problem can be avoided by

  1. uninstall all nvidia driver packages before the version upgrade
  2. perform the system version upgrade
  3. perform the steps given by the rpmfusion how-to linked above
  4. reinstall the nvidia drivers and the new driver will be signed and load properly.

If the user has already done the upgrade and the nvidia driver will not load the following will work to fix the issue.

  1. perform the steps in the rpmfusion how-to linked above
  2. remove the kmod-nvidia package built for the latest kernel. For the initial kernel with the fedora 36 release that is the 5.17.3 kernel and can be done with dnf remove kmod-nvidia-5.17.3-302.fc36.x86_64.x86_64
  3. reinstall akmod-nvidia
  4. reboot to force akmod to rebuild the nvidia modules with the key already generated in step 1 above. The nvidia module should now load properly.
1 Like

Thanks for a guide. Can you report a bug against nvidia driver in rpmfusion? Perhaps there is a way this could work more automatically (I have no idea, but it’s worth asking). If it can’t, why don’t you edit the linked wiki page and add a section on nvidia-related steps? (You might need to create an account). That way the full guide can be found in one place, instead in two.

1 Like

We’re discussing whether #common-issues is the right place for such guides as this one in Migrate Quick Docs from Docs site to Ask? - #32 by kparal .

+1, it’s best to contact RPM Fusion so that the information on their wiki page can be updated. There’s no reason why this information should live separately here (or on quick-docs) IMO.

I disagree a bit with that: this is the place where most/many users end up for problem solving. I would question if any average user knows that he/she has to look on rpm fusion for this issue (quite sure many won’t even recognize which package is installed from which repo; or which software has a wiki/bugzilla at which place).

@mattdm made a good point some days ago about the fact that bug filing is a capability not everyone has, and thus we should not always close an issue here and assume that the user should just file a bug. I think this is the same: we should not anticipate this knowledge but try to help solving problems that might appear on the Fedora operating system. So, work more issue-based/problem-oriented and not based on the repo/package/development structures (which are not comprehensible to many). Does that make sense somehow? :slight_smile:

However, I agree that avoiding redundancy by focusing on providing links instead of additional content makes sense if applicable.

I don’t think I understand this very well. People have to go to the RPM Fusion repositories to install Nvidia drivers. So won’t this information fit there?

Also, we want them to know that they have to go to RPM Fusion so that there’s the opportunity for them to wonder and learn why this is so. It’s a very important step that helps them understand our stance on FOSS—our first foundation. So, we want them to know that “Fedora promotes Free Software, and Nvidia does not currently provide a FOSS driver. Fedora will not provide the proprietary driver—we want you to use nouveau if possible. If not, please go to this community resource to install the proprietary driver yourself”.

(Similary, for music codecs, we want people to be aware of patents and copyright.)

We’re not here to just make an OS—we’re here to promote FOSS, and our chosen method is by making various FOSS platforms. We want it to be easy for users to use Fedora, but if we can do it without completely skipping over the importance of FOSS, that’ll be good (and usability and this little bit of education are not mutually exclusive).

We don’t do this. We help people diagnose the issue, isolate the component, and then file bugs if necessary. And for the last bit, we have a whole quick doc dedicated to filing a bug:

I understand what you’re saying, but one cannot diagnose/debug issues at an operating system level. The whole point of debugging is to be able to isolate the particular component that is causing the issue, and then contacting the person in-charge (the expert). It’s like a car breaking down—it cannot be fixed without isolating the broken bit. The driver does not need to know the internals if they don’t want to fix their car themselves, but if they do, they’ll need to be able to isolate the broken bit—which is what we help people do here on the forum. If we were $company that was providing software and support in return for a fee, we too would have service contracts where someone would go fix issues for the user—a mechanic—but that’s not how community based distributions work and we shouldn’t try to replicate that system.

Anyway, I don’t see how any of this leads to “this documentation which is specific to the Nvidia driver installed from RPM Fusion should live somewhere other than at RPM Fusion”.

If we start to keep stuff here on the forum and do not make an effort to contact the authoritative sources of information, they never get feedback. The RPM Fusion community (and other third party communities) cannot be expected to monitor this and every other Fedora forum there is—we have to point users to them. It also ensures that they get credit for the work they do to support Fedora users, which is very very important.

Sorry! You got me wrong. I absolutely agree about forwarding information and facilitating the established (distributed) FOSS institutions! There is no doubt about that. I just meant that having a user-oriented problem solution here additionally makes sense because nearly any user will be able to end up here on himself/herself, but not on the rpmfusion wiki (just as an example). So, I see a reason why this information should live here separately: for the average user who seeks issue-based/problem-oriented structures (which can be found with information limited to the symptoms of the appearing problem) without upstream, downstream and different repos in mind. That’s all :slight_smile:

People try to get their package the usual way (package manager, gui, cli), if they don’t find it, they check on the Internet how to get it and this may lead them to rpmfusion. Therefore, they will get in touch with rpmfusion through one package (maybe its nvidia, maybe its vlc, …).

When they want to get a package (maybe nvidia, maybe vlc, …) the next time, they do the same: check the usual way… and now they get it because rpmfusion is already installed.

Does any user check the repo he/she is installing from when using dnf? Or know what implications that has for problem solving and such? If they read the reasons for why they need rpmfusion, they know it is linked to licenses and patents, not to problem handling.

Does any user remember that he/she installed rpmfusion and for which purpose it was? They do what google tells them when they want to get the nvidia driver; and not everyone recognizes what this rpmfusion thing is all about and what implications it has for problem solving or so.

This example is a bit rough I know, but I think it illustrates my point.

So, I disagree with the assumption that the way people get in touch with rpmfusion makes them automatically know that they have to seek nvidia solutions on an rpmfusion-related wiki page. Also, does any user know the link between repo and wiki?

I generally like your arguments and would even agree that an os for advanced users should anticipate all that knowledge. But Fedora claims for itself that it is not just for experts.

Maybe my arguments are a bit daring, but they reflect my experiences on ask.fp :smiley:

I hope, this time it makes sense :slight_smile: Now that I read your response, I admit that my original post can be misinterpreted.

I did not file a bug at rpmfusion because I cannot. Had I been able to I certainly would have.

Since rpmfusion has seen fit to not allow anyone with a gmail address to log in and file bugs there are many who would do so but are blocked by their policy (myself included).

I personally feel info should be posted both places.

  1. rpmfusion needs to approach this in a way that makes it more automated and less dependent upon a users expertise.
  2. The issue which will certainly affect many should be here in common issues since not all will know it is related to the driver being built without the signed key.

As I noted above and in the linked thread there is a work-around as well as a way to avoid the issue entirely, but it does require some thought and experience / expertise in the matter. Many do not even like using dnf on the cli and the solution following the how-to from rpmfusion does not work automatically. It will only work properly if the instructed steps are followed to create the signature and import the key before the nvidia driver is installed. Otherwise the user has to take steps to create the signed driver manually or wait until the next kernel update when the driver will be automatically rebuilt.

I opened this thread since I feel it will be common to many who wish to use secure boot but have not been doing so because of the nvidia driver. Having the ability to easily sign kernel modules as is now available in F36 also carries the need for users to become used to doing the signature steps before those modules are created.

If the steps are not here in common issues then it probably should be considered as a ‘quick docs’ topic (or maybe even both places)

With the nvidia driver from rpmfusion the fix is relatively easy since the akmod-nvidia package builds the kmod-nvidia package for the user. With other packages that do not use akmods that may be another topic entirely.

What about the people who install the driver by downloading directly from nvidia? I often see posts from users who do that or install from another repo such as negativo. They do not even see info from rpmfusion (and may not be aware of the [easy] ability to create a signature now that F36 is released and contains the tools to do so)

That’s odd. I use my g-mail address for RPM Fusion’s bugzilla. Is this policy noted somewhere?

They will, but someone has to discuss this with them to see what the best way forward is. RPM Fusion is also a volunteer community, in fact made up mostly of volunteers who also contribute to Fedora. So just like we shouldn’t say “someone in Fedora should do this”, we shouldn’t say “RPM Fusion should do this…”. We should go help them do it :slight_smile:

From what I’ve read, the current recommendation is to simply disable secure boot if one needs to use the nvidia blob. I think that’s the path most users will go—because if we’re assuming people aren’t technical enough to know what repos they get their packages from, they will also not likely be technical enough to create a new key etc. It’s not a trivial undertaking, and I can’t see a lot of folks doing this at the moment.

They should not be doing so—the whole point of the RPM Fusion kmods is to prevent users from using the binary blob that nvidia provides them with. The binary blob creates so much trouble that RPM Fusion even has a special entry on how to recover from it:

(The first thing we say to anyone here on the forum is to not use the Nvidia blob, and point them to RPM Fusion.)

Sure, and that’s just Discourse by design. The first time someone runs into issue A, they ask a question here—we help them out, fix the issue, and then that solution becomes available to everyone else who may run into issue A.

The discussion is more on “what should be the authoritative source of information”. Should it be Ask Fedora here, or RPM Fusion’s wiki where all information on Nvidia driver installation lives and is maintained by the RPM Fusion maintainer? In this case, I would suggest it be RPM Fusion, and topics here would point users to the information on RPM Fusion—similar to how we point people to the quick-docs etc.

I was unable to register with my gmail account as well, I had to utilize another email address.

Since a user can install via gnome software without ever having to look at rpmfusion the more visibility this has the better.

I have tried repeatedly to create an account for bug reporting at rpmfusion and the message that comes back is that they do not allow users with gmail accounts to have an account because of spam.
This is the screen I get when I attempt to create an account at

I agree, and I have been running with secure boot disabled for years.
I went through the steps to enable secure boot and still use the nvidia drivers because of the linked thread I posted above. This is why and how I found the issue.

Many if not most will not see a problem if they still are comfortable with secure boot disabled, but if they wish to enable secure boot it can bite them.

One fix that I could see would be if the rpm to install akmod-nvidia had a pre-install script to look and see if the version were fedora 36 or higher and if the key were already generated. If F36+ and no key it could run the 2 steps shown at rpmfusion for the user

mokutil --import /etc/pki/akmods/certs/public_key.der

Doing this automatically would also require the user to enter a password during the mokutil step and they would need to know that the same password would be needed during the next boot to import the key to the bios so it would require thought on how to tie the events together.

Importing the key to bios should be possible whether secure boot is enabled or not, but it really would depend on the bios itself.

1 Like

Ah, I see. We had similar spam issues in Fedora which is why now folks have to be at least part of one FAS group before they can edit the wiki etc. I can ask the RPM Fusion admins again if there’s a better way of dealing with the spam.

In the meantime, does using instead of work? (They point to the same mailbox).

I don’t think this will work—dnf updates are designed to be non-interactive :confused:

Whatever the solution is, given that it involves the RPM Fusion kmods, it needs to be discussed on their channels so that the maintainer can see what is possible here.

I am not deep enough into the workings of the development to know who to approach with something of this sort; which is why I posted here and also suggested a potential quick doc for user reference.

At least this way users can find a work-around even if it is not really a clean and permanent fix that avoids user interaction.


Since the F36 will be out next week and I need to clean up these categories, I’m moving this into #english . I leave it up to @mattdm to figure out where best to place it and if a “How to/Guides” category should be created for posts like these.