# Nvidia-Fedora-Guide: replacing Nouveau with NVIDIA drivers on Fedora

> The Nvidia-Fedora-Guide is a written procedure for installing NVIDIA proprietary drivers on Fedora Workstation, its KDE and Cosmic spins, and the Atomic desktops, with the Secure Boot key enrollment and LUKS caveats that usually trip people up. It is aimed at Fedora users with an NVIDIA card, not at a general Linux graphics audience.

**fady-saied/Nvidia-Fedora-Guide** — A complete guide on getting Nvidia's Proprietary drivers for Fedora desktops (Workstation, KDE and Atomic) with instructions for Secure Boot and encrypted drives.

- Repository: https://github.com/fady-saied/Nvidia-Fedora-Guide
- Stars: 629 · Forks: 28
- Language: Unknown
- License: CC0-1.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/fady-saied-nvidia-fedora-guide

## What the guide actually covers, and which desktops it claims

The repository is documentation, not code. The top level holds only a LICENSE file and a README, so there is nothing to install and nothing to run. The whole deliverable is a sequence of commands with the reasoning attached.

The scope is deliberately narrow. The guide targets Fedora Workstation with its Gnome, KDE and Cosmic spins, and the Atomic desktops Silverblue, Kinoite and Sway. It says it was tested for Gnome, KDE, Cosmic and Sway, and warns that other desktop environments may require extra steps. It also states outright that it is made strictly for Fedora Workstation and its spins and for Fedora Atomic, so an Ubuntu or Arch user gets no help from it.

The problem it solves is the standard one: Fedora ships the open source Nouveau driver by default, and to run the proprietary NVIDIA driver you need an external repository, a kernel module built against your kernel, and a signed module if Secure Boot is on. The guide handles all three in one ordered flow.

The licence is CC0-1.0, so the text can be reused without attribution obligations. The README also asks readers to file an issue if they hit a failure, and points to a short survey at the end that the author says helps decide which failures to document first.

## Secure Boot is the step that decides whether the rest works

The guide names the hard part immediately: Secure Boot blocks the driver modules from loading unless they are signed. The first thing to do is check the current state, and the check is a single command.

```bash
mokutil --sb-state
```

If the output shows Secure Boot enabled, the extra key enrollment steps apply. If it is already disabled, the guide says to skip the enrollment step entirely. The advice on whether to keep Secure Boot on is honest rather than ideological: do not disable it if it was already enabled for security, and only disable it as a fallback if the modules still fail to load after the signing steps were done correctly.

The signing chain is the standard akmods path. The guide installs the tooling, generates a key, and imports the public key into the Machine Owner Key store.

```bash
sudo dnf install kmodtool akmods mokutil openssl
```

```bash
sudo kmodgenca -a
```

```bash
sudo mokutil --import /etc/pki/akmods/certs/public_key.der
```

A note warns that if the key generation reports an existing key pair, you add `--force` and run it again. The import prompts for a password, and the guide is specific that you should pick a short one such as 0000 because the MOK screen is QWERTY regardless of your keyboard layout, then reboot, select Enroll MOK, confirm with Yes, and enter that same password.

## RPM Fusion and the system update come before anything else

The preparation section is two steps, and both are non-optional in practice. First, the system has to be current, so that the akmod package is built against the kernel you are actually running.

```bash
sudo dnf update
```

Second, RPM Fusion has to be enabled, because that is where the NVIDIA driver packages live. The guide gives a single command that installs both the free and the nonfree release packages, with the Fedora version resolved at install time by `rpm -E %fedora` rather than hardcoded.

```bash
sudo dnf install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
```

The command reaches out to mirrors.rpmfusion.org, and the guide adds a tip for the case where that URL returns a 404 or an error: download the configuration file from rpmfusion.org/Configuration instead. That is a real dependency on a third party mirror, and it is worth knowing before you need it.

The guide is candid about the format of the whole thing. It says you will mostly need to copy and paste commands into the terminal, but that you should read everything carefully, which is a hint that the order of the steps matters and that a skipped step resurfaces later as a black screen.

## Picking the driver branch from your GPU, not from your preference

The install step branches by hardware age, and the guide makes you identify the card first.

```bash
lspci | grep -iE 'VGA|3D|nvidia'
```

For GPUs from 2017 or later, the current GeForce, Quadro and Tesla range, the packages are the plain akmod and the CUDA variant, and the comment on the second line explains why it is installed: it is required for nvidia-smi and CUDA support.

```bash
sudo dnf install akmod-nvidia
sudo dnf install xorg-x11-drv-nvidia-cuda # Required for nvidia-smi and CUDA support
```

For the older GTX 800, 900 and 10 series after Fedora 44, the guide points at the 580 driver packages instead.

```bash
sudo dnf install xorg-x11-drv-nvidia-580xx akmod-nvidia-580xx
sudo dnf install xorg-x11-drv-nvidia-580xx-cuda # Required for nvidia-smi and CUDA support
```

The reason for the split is stated in a note: since driver v590 and later on Fedora 44, support for the GTX 800, 900 and 10 was dropped, so those cards need the v580 drivers. A second note scopes the 580 branch to Maxwell and Pascal GPUs from between 2014 and 2017.

The oldest branch, the 470 driver, is for the GeForce 600 and 700 series and other Kepler cards, which the guide identifies by the K prefix and by naming specific GTX 700 and 600 series models.

```bash
sudo dnf install xorg-x11-drv-nvidia-470xx akmod-nvidia-470xx
sudo dnf install xorg-x11-drv-nvidia-470xx-cuda # Required for nvidia-smi and CUDA support
```

That branch carries an extra requirement: because it is an X11 driver, you also need an X11 session installed on KDE, and the guide warns that Gnome 49 or later is therefore not an option for Kepler users, who must use KDE or another X11 capable window manager.

## Sway and Atomic need two environment lines before the driver behaves

The Atomic desktops are not a separate procedure in the guide, but they do carry their own caveat, and Sway carries a specific one. For Sway and Sway Atomic, which the guide also calls Sericea, you are told to open `/etc/sway/environment` and uncomment or add two settings.

The first is `SWAY_EXTRA_ARGS`, which is extended with the `--unsupported-gpu` flag, and the second is `WLR_NO_HARDWARE_CURSORS=1`. The guide does not explain in detail what each flag changes at the compositor level, so treat them as a documented requirement of the procedure rather than as something to tune.

That is the whole Sway specific part, and it is worth noting how small it is. The bulk of the work, RPM Fusion, akmods, the MOK enrollment and the driver packages, is shared with the GNOME and KDE paths. The differences between the desktops are configuration files and one warning about Gnome version support for legacy hardware.

Atomic desktops differ from Workstation in package layering, and the guide does not open that subject. The Atomic walkthrough is not covered in this description, so anyone following the guide should read the Atomic chapter in the repository itself rather than assuming the Workstation steps apply unchanged.

## Encrypted drives and hybrid laptops are the two failure modes named upfront

Two problems get warned about before the driver install, and both are about the machine, not the package.

The first is LUKS encryption. The guide says that users with encrypted drives follow extra steps after installation, and it repeats the warning in the preparation section: the extra steps must be done before the final reboot to avoid a black screen on startup. The table of contents lists a dedicated section for encrypted drives. Treat the order as non-negotiable and read that section in the repository before rebooting.

The second is hybrid graphics. On a hybrid laptop with an external monitor connected to the NVIDIA GPU over HDMI, the guide says you might see severe lag on the external display once the proprietary drivers are in place. Two fixes are offered. You can use the MUX switch to disable the integrated GPU, or you can follow a linked workaround article for solving low FPS on an external monitor under Linux. The guide presents the second as a workaround to apply after the drivers are installed.

Both of these are hardware and firmware interactions, and neither has a command you can run to verify the outcome. That is the honest limit of a written guide: it can tell you the correct sequence, but the confirmation that the sequence worked is what the reader observes on their own screen.

## What this repository is, and where it stops

A fair assessment has to start with what is not here. The repository contains a LICENSE and a README, and nothing else, so there is no install script, no RPM file, no Ansible role and no automated test to run. Every command is a command you read in a document and paste into a terminal yourself, and the guide says as much when it tells you that you will mostly need to copy and paste commands but should read everything carefully.

That has consequences. The guide cannot be validated for you the way a package can, the failure cases it lists are the ones the author personally hit, and the survey at the end is an admission of that: the author says the survey helps maintain the guide, especially for people who hit a failure during installation. There is no changelog to diff, no GitHub releases to compare, and the version of the guide is whatever the README says on the day you read it.

The alternative approach, and it is a real one, is to keep the Nouveau driver and accept its limits, or to use the distribution's own packaged NVIDIA modules where the distribution provides them. The difference in approach is ownership: this guide gives you a signed akmod module and the MOK key enrollment that makes Secure Boot accept it, so you own the key and the signing process, while a packaged path hands you a module that someone else already signed for a different kernel and driver version. Ownership costs you the key enrollment steps, the MOK password, and the knowledge that an akmod rebuild happens on every kernel update.

The last push was on 2026-10-17, and the README tracks Fedora 44 driver branches by name, so the guide is being kept in step with a moving distribution. It is worth re-reading the driver branch section each time Fedora ships a new kernel.

## Conclusion

Use this guide if you run Fedora Workstation, a KDE or Cosmic spin, Silverblue, Kinoite or Sway on an NVIDIA card and want a written, ordered procedure instead of forum snippets, and if you can follow it in order on a machine you can reinstall. Do not use it for other distributions, for a machine whose Secure Boot state you cannot check with mokutil, or as a script, because the repository contains only a README and no automation at all. Before you start, confirm your GPU generation with lspci, read the LUKS section if your drive is encrypted, and keep the MOK password you set during enrollment, since losing it means redoing the Secure Boot steps.

## FAQ

### How do I install NVIDIA proprietary drivers on Fedora with the Nvidia-Fedora-Guide?

The guide runs in order: update the system with `sudo dnf update`, enable RPM Fusion, install the signing tools with `sudo dnf install kmodtool akmods mokutil openssl`, generate a key with `sudo kmodgenca -a`, import it with `sudo mokutil --import /etc/pki/akmods/certs/public_key.der`, reboot to enroll, and then install the driver packages that match your GPU.

### How do I check whether Secure Boot is enabled on my Fedora system?

Run `mokutil --sb-state` in the terminal. If Secure Boot is enabled, the key enrollment steps are required so the driver modules can be signed and loaded; if it is already disabled, the guide says to skip that step.

### Which NVIDIA driver should I install on Fedora for an old GTX card?

The guide splits by hardware generation. GTX 800, 900 and 10 series use the 580 packages after Fedora 44, since support was dropped in driver v590 and later, while GeForce 600 and 700 series and other Kepler cards use the 470 packages and also need an X11 session on KDE.

### What do I do if my Fedora machine boots to a black screen after the NVIDIA install?

The guide says that users with LUKS encrypted drives have to follow extra steps after installation to avoid a black screen on startup, and that those steps must be taken before the final reboot. It also notes that if the driver modules still fail to load, disabling Secure Boot is the fallback.

### Does the Nvidia-Fedora-Guide support Silverblue, Kinoite and Sway?

Yes, the guide states it is made strictly for Fedora Workstation and its spins, including KDE and Cosmic, and for Fedora Atomic desktops including Silverblue, Kinoite and Sway. Sway users are told to add two settings to `/etc/sway/environment`, including `SWAY_EXTRA_ARGS` extended with `--unsupported-gpu` and `WLR_NO_HARDWARE_CURSORS=1`.

## Sources

- [fady-saied/Nvidia-Fedora-Guide on GitHub](https://github.com/fady-saied/Nvidia-Fedora-Guide)
- [Issues](https://github.com/fady-saied/Nvidia-Fedora-Guide/issues)
- [License: CC0-1.0](https://github.com/fady-saied/Nvidia-Fedora-Guide/blob/main/LICENSE)
- [README](https://github.com/fady-saied/Nvidia-Fedora-Guide/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fady-saied-nvidia-fedora-guide