[TOOL] NVIDIA Easy Automatic Driver Installer for Fedora 32 Workstation or above

I have created a CLI tool which lets you install proprietary NVIDIA drivers easily in Fedora 32 Workstation or above. The look and feel is heavily inspired from systemd and eopkg prompts.

You can find the repository here and the tool release here. Do give it a try :smile:


  • Active internet connection
  • Fedora 32 Workstation or above


  1. Make sure you have a working internet connection
  2. Download NVAutoInstFedoraWS32 from releases
  3. Grab a terminal and make that location your working directory
  4. Execute ./NVAutoInstFedoraWS32 to install drivers
  5. Give stars to the repository if you found this helpful


  • Requires secure boot to be turned off in UEFI systems.
  • Requires superuser access for repo addition and driver setup.
  • Active internet connection is required to download drivers.
  • The drivers are fetched from the RPMFusion repository.
  • Discrete cards from 9XX/10XX/20XX series only are supported.
  • Native support for PRIME configuration is coming soon.
  • No additional configuration is required for Optimus setups.
  • Consider using executables provided in releases section only.

Coming soon

  • CLI “Launch using Dedicated Graphics Card” option.
  • Intuitive mode switching for hybrid graphics.
  • Distinct mode for using integrated or discrete GPU.
  • Option to install CUDA, NVENC/NVDEC and more.

Thanks for the efforts. It would be good to know what is the purpose of this tool, instead of installing directly from RPMFusion or negativo17.


Thanks for your work on this!

A quick note:
RPM Fusion is either written “RPM Fusion” or “rpmfusion”.

I haven’t reviewed the code itself, but it should be relevant to have packaged in the rpmfusion nonfree section. (maybe the name should be simplified so that it can be relevant for other Fedora spins).

There are many corner cases that need to be taken care off, so this is very welcomed !


This is the “direct” method. A not-so savvy user or some one with less time to spare might not want to go through the documentation and add the repositories again, before installing the driver and their dependencies. This one tool does it all for you from a single place.

Thanks for the insight about RPM Fusion - I’d make changes soon and it would be reflected in the next revision. Also, I have linked my repo so feel free to take a look at the code.

The reason why I am specific about Workstation and the listed graphic cards is because those are resources I was able to test on. If someone running a spin could test and confirm it to be working, I can surely generalize it for other spins.

Please take a look and let know how I can improve upon this. I’d be obliged.

Hi t0xic0der, that’s really nice, well done!

I would like to circle back to a point I had made when you posted your guide. There is no need to wait for 5 minutes. On my not very fast laptop, the whole thing is done in 25-40s depending on load. That’s a lot of time wasted, especially if there is a failure.
Your script should be keeping an eye on the actual process and I can think of none other more qualified than @kwizart to help you check the exit code of the akmod transaction.


Thanks for trying this out, @alexpl

Right. That is kind of a blind wait as of now but kind of ensures that things would most likely work. But in order to automate this, I should be able to track if the event took place or not.

@kwizart Looking forward to your assistance. You can find the link of my repo at the original post. I am in Fedora Join SIG Telegram group there so we can discuss as to how we can monitor the status of the akmod transaction. :smile:

@alexpl I wish I had testers for this. That would very much bring down the times I would have to shoot arrow in the dark. :innocent:

Could you please elaborate? :slight_smile:

He’s saying, with some polish this could easily become an RPM Fusion package; makes sense considering it’s using the repos. (Not sure why it would have to live in the nonfree section, though; is there some rule prohibiting even freely-licensed packages from living in rpmfusion-free if they have nonfree dependencies even indirectly, @kwizart?)

A few thoughts/suggestions, though I can open issues for some/all of these in the Github repo if you prefer.

  1. Nothing needs that many exclamation points. Obtaining “compatibility information” for my graphics card is not a cause for celebration or excitement.

  2. Do yourself a favor and at the very least create a class of string aliases, something like:

    class Status:
        SUCCESS = Style.BRIGHT + Fore.GREEN + "[ ✔ ]" + Style.RESET_ALL + " " + Fore.WHITE
        FAIL = Style.BRIGHT + Fore.RED + "[ ✘ ]" + Style.RESET_ALL + " " + Fore.WHITE

    So you can just print(Status.SUCCESS + "Message" + Style.RESET_ALL).

    Or better yet, a Status class with a set of class methods that take string arguments and do all of the necessary decorating and printing, so you can just write lines like Status.success("Message") and Status.failure("Message").
    It’ll greatly reduce repetitive code duplication, and more importantly allow you to change how things are formatted in one place instead of having to make identical edits to 20 lines of code.

  3. “if lspci line count != 1” is a bad way to identify Optimus/PRIME configurations. It’ll mis-classify any system with two or more discrete GPUs.

  4. You say “Discrete cards from 9XX/10XX/20XX series only are supported.” but that’s just not true. There’s nothing I can see that would fail to work with older cards, and more importantly nothing in the code that limits support to only those cards — or any cards. Literally any GPU that has “NVIDIA” in its PCI ident string will be recognized.

  5. That previous point is an issue for older cards that aren’t supported by the current driver series (currently that’s any card not on the Supported Products listing here, roughly anything before GeForce 630 / Quadro 410) — it’d be cool to have some way of detecting older cards and automatically switching to the appropriate 390.xx, 340.xx, or 304.xx (forgot, those were dropped) legacy driver as needed. That’s admittedly a tall order, though, as you’d probably have to both convert that support list to some parseable form, and constantly keep it up to date with newer releases. But at the very least, it’d make sense if the tool refused to install the current drivers on systems with GPUs they won’t support.


Oh boy. I would love to see that happening. :grin:

@ferdnyc All the points you noted are indeed valid and need looking into. Please go ahead and create issues for each of these in GitHub. :slight_smile:

I would definitely need some assistance in solving this.

I claimed so because these are the only cards that I was able to test with. It would have been wrong (to my conscience) if I would have claimed it to be working on some other cards when it was not tested on them.

I admit it can be a long haul but it is worth doing as it would also address people owning older GPUs.

Would you be willing to contribute? @ferdnyc :hugs:

I have very little experience with switchable-GPU type setups, my one laptop contains only an Intel GPU. But AIUI, all switchable GPU laptops pair an Intel GPU with a higher-end discrete chip, correct? So, identifying those systems might be as simple as searching for a second line in the output that contains “Intel”.

(Well, scratch that — it still won’t be able to discriminate between Optimus/PRIME and systems like one desktop I had, where the motherboard used a sucky Intel GPU, so I stuck an Nvidia card into it and just used that instead, ignoring the motherboard GPU.)

And that’s laudable, but I would say it that way: It’s only been tested with those cards, but should work with any GPU supported by Nvidia’s current driver series.

Sure, I’ll try to get to that this evening.

1 Like

Great…! It’s good for us …thanks

1 Like

Hi @kwizart. If you find time, do head over to the issues page of the project. I and @ferdnyc have been listing things that should be addressed (and have also begun to work towards it) :slight_smile:

v0.2.0 released (27 May 2020, 14:54IST)
Made a lot of changes and fixed a lot of bugs to get the v0.2.0.

What has been improved upon?

  • Cleaned up repeated code using class implemented decorator calls (as per @ferdnyc’s suggestions)
  • Enforced root access for whole operation instead of sudo implementation (was going to be polkit but it seemed impossible for the other spins to make that)
  • Added support for x86 libraries of Xorg display server (addressed requests from some reddit user whose name I don’t remember - useful for Steam, DXVK etc)
  • Added distribution identification with support status display (Thanks for the suggestion @ferdnyc)
  • Scaled up to accompany Workstation as well as Fedora Spins (Generalized for all as per @kwizart’s suggestion)

What bugs were fixed?

  • Added dedicated status check for driver installation (The tool previously used to proceed blindly)
  • Added dedicated status check for kernel module reader (The tool previously used to proceed blindly)
  • Fixed confirmation choice during package check (Minor bug during Y/N choice)
  • Fixed typo in RPM Fusion mentions throughout the tool interface (Addressed @kwizart’s suggestion)

This is what I would work on, down the line.



It kinda looks a bit different too. (Just a bit)


I don’t know how far you have been by replacing the sleep after akmods installation. But at least you should be able to poll the availability of the nvidia.ko using modinfo
Please verify to be on the latest kernel or you will need to

On second thought, using python will requires you do lot of bolder plates.
It might be more relevant to move to use “ansible” instead…
It still interesting work!

Thanks @kwizart for the response.

Got it. I will get the output of modinfo -F version nvidia to start with.

This is my plan of action to ensure if the module has been successfully installed or not.

  • First I will check the output of modinfo -F version nvidia.
  • If I get modinfo: ERROR: Module nvidia not found, I will wait for some 5 seconds and check again.
  • I will wait for a specific timeout to take place, (eg. 5 mins) for detection and I will timeout if not detected.
  • Not everyone has to wait for a complete 5 minutes. Most would be done with the modinfo check under 5-10 seconds (at max).

In most of the setups, I believe the modinfo check would get passed in the very first attempt - still keeping the timeout for PCs which take time to build modified kernel modules.

I will build the stuff I specified above and will test it against the latest kernel. There is 99.99% chance that it will work. :wink:

I did not get what you mean by saying that. Could you please explain?

Also, I am thinking that maybe these two are not needed as the process of building the modified kernel module begins automatically, immediately after the installation is over.

sudo akmods --force
sudo dracut --force

Could you please confirm this? @kwizart

v0.2.5 released (31 May 2020, 10:38IST)
Made very important changes and fixed some bugs to get the v0.2.5.

What has been improved upon?

  • Removed that nuisance mandatory sleep time for kernel module load. (as per discussion here)
  • Removed dependency on kernel module loader (as per discussion here)
  • Removed kernel module force-read altogether (no sudo akmods --force or sudo dracut --force anymore)
  • Defaulted textual messages to autocolor for better legibility (functionable visibility in themed terminals also)

Bugs fixed

  • Fixed boolean choices in main function
  • Fixed boolean choices in package check
  • Fixed prompt colors for custom-themed terminals

This is what I would work on, down the line. All the issues would be paid equal amounts of attention but there is a dire need of testers for the spins. Feel free to comment under the issue on which you can be assistance. :slight_smile:

This is kind of a big update as it does away with the unnecessary wait times for kernel module loading and forced akmods creation after the installation has completed. The five-minute wait was indeed an inconvenience an modified kernel modules are loaded way before that time even in the slower PCs so it is not worth waiting so long. Also, the akmods transaction commences immediately after the installation gets over and does not let you turn off the PC right away before the modules are completely built so there is no reason why you should force building modules via akmods and dracut.

1 Like