Fedora is one of those distributions that gets bleeding-edge kernels, GNOME releases, and toolchains faster than almost anyone else. That’s exactly why NVIDIA support has always been a slightly awkward relationship. Fedora ships with the open-source Nouveau driver out of the box, which is fine for a desktop that only needs to render a terminal and a browser, but the moment you plug in anything demanding — a game, a CUDA workload, a multi-monitor setup with high refresh rates — Nouveau starts showing its limits. No hardware acceleration for video decode, no proper power management, and performance that feels like driving a sports car with the parking brake half-engaged.

Fedora 44, released in late April 2026, brings kernel 7.0, GNOME 50 running Wayland-only, and a switch to dnf5 as the default package manager. Those changes matter for NVIDIA users specifically, because kernel version bumps have historically been the number one cause of “my driver worked yesterday” support threads. If you’ve been burned by a kernel update that silently broke your akmod build on a previous Fedora release, you already know why this guide spends extra time on verification steps most tutorials skip entirely.

This walkthrough covers the RPM Fusion method, which remains the correct approach for the vast majority of installs — it’s maintained, it survives kernel updates automatically, and it plays nicely with Secure Boot once you understand the signing step. We’ll also touch on the NVIDIA runfile method for edge cases, cover Wayland-specific quirks introduced by GNOME 50, and walk through the troubleshooting scenarios that actually show up in production and daily-driver machines, not the sanitized examples you find in official docs. By the end, you’ll have a working driver, a verified kernel module, and enough understanding of why each step matters that the next kernel update won’t catch you off guard.

Why Fedora Doesn’t Ship NVIDIA Drivers by Default

Fedora’s parent project, Red Hat, has a strict policy around including only free and open-source software in the base repositories. NVIDIA’s proprietary driver doesn’t meet that bar, so it’s excluded — same reason you won’t find certain codecs or Flash-era plugins baked in either. This isn’t Fedora being difficult; it’s a legal and philosophical stance that’s been consistent since the project’s inception.

That’s where RPM Fusion comes in. It’s a third-party repository, run by community maintainers who track Fedora releases closely, and it packages NVIDIA’s driver in a way that integrates with dnf and rebuilds automatically against new kernels using akmod. Think of akmod as a wrapper around DKMS-style automatic kernel module rebuilding, specific to the RPM-based ecosystem. Every time you install a new kernel, akmod quietly recompiles the NVIDIA module against it in the background. That’s the entire reason RPM Fusion is preferable over manually running NVIDIA’s .run installer script for 95% of use cases — the runfile method doesn’t know or care about your next kernel update, and it will absolutely leave you with a black screen after dnf upgrade if you’re not careful.

Before You Start: Pre-Flight Checks

A few minutes of verification here saves an hour of troubleshooting later. This is the step most guides skip, and it’s the one that separates a clean install from a support thread titled “help my Fedora won’t boot.”

Confirm Your GPU and Fedora Version

lspci -k | grep -A 3 -i "VGA\|3D"
cat /etc/fedora-release
uname -r

You want to see your NVIDIA card listed and confirm you’re actually on Fedora 44 with a current kernel. If lspci shows the card being handled by nouveau in the kernel driver line, that’s expected pre-install — it’ll change to nvidia once we’re done.

Check Secure Boot Status

mokutil --sb-state

If it reports SecureBoot enabled, note that down. It changes one step later in this guide, and skipping it is the single most common reason people end up stuck at a black screen after reboot with “signature verification failed” buried somewhere in the kernel log.

Update the System First

sudo dnf upgrade --refresh
sudo reboot

Reboot before installing the driver, not after. Installing akmod-nvidia against an old kernel and then upgrading the kernel in the same session is asking for a mismatch between the running kernel and the built module. It’s a small ordering detail, but it’s exactly the kind of thing that turns a 10-minute install into a 40-minute debugging session.

Step 1: Enable RPM Fusion Repositories

RPM Fusion splits into “free” and “nonfree” repositories. NVIDIA’s driver lives in nonfree, but you need both enabled because some supporting packages (codecs, certain libraries) live in free.

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

That $(rpm -E %fedora) bit is worth understanding rather than just copy-pasting blindly. It’s bash command substitution that resolves to your installed Fedora version number, so it expands to 44 automatically on Fedora 44. The upside: this exact command works unchanged on the next Fedora release too, since it always pulls the correct version at execution time instead of hardcoding it.

Refresh the metadata once the repos are in:

sudo dnf makecache

Step 2: Install the NVIDIA Driver via akmod-nvidia

With Fedora 44, RPM Fusion ships the 595-series driver branch by default for supported hardware, and it’s dropped support for GPUs older than the Pascal architecture (GTX 900 series and earlier are no longer covered by the current branch — more on legacy handling below).

sudo dnf install akmod-nvidia

If you need CUDA support for machine learning workloads, video encoding/decoding via NVENC/NVDEC, or GPU-accelerated Blender renders, add the CUDA package in the same breath:

sudo dnf install akmod-nvidia xorg-x11-drv-nvidia-cuda

Mark the package as user-installed so dnf’s autoremove logic never sweeps it away as an orphaned dependency during a routine cleanup:

sudo dnf mark user akmod-nvidia

This is a small habit worth building. It’s saved more than one system from a driver disappearing after a dnf autoremove run that the user didn’t think twice about.

Step 3: Let the Kernel Module Build — Don’t Rush the Reboot

This is where impatience causes 90% of “the install didn’t work” complaints. akmod-nvidia doesn’t compile the kernel module immediately during dnf install. It queues the build, and akmods picks it up shortly after, compiling against your currently running kernel headers in the background.

Give it a few minutes. On modest hardware this can take anywhere from two to eight minutes depending on CPU speed and whether it’s building against multiple installed kernels. You can force and watch the build directly instead of guessing:

sudo akmods --force

Once that completes without errors, verify the module actually built and has a version string:

modinfo -F version nvidia

You should see something like 595.xx.xx printed back. If instead you get “modinfo: ERROR: Module nvidia not found,” the build hasn’t finished, failed silently, or the kernel headers didn’t match. Don’t reboot yet if this comes back empty — rebooting into a system with no working display driver and Nouveau blacklisted (which some setups do) is how people end up googling from their phone at 1am.

Rebuild the initramfs so the module is available during early boot, particularly important if you’re using modesetting for a smoother Plasma or GNOME 50 Wayland session:

sudo dracut --force

Step 4: Secure Boot — The Step Most Tutorials Gloss Over

If your earlier mokutil --sb-state check showed Secure Boot enabled, this part is not optional. Fedora’s kernel enforces module signature verification when Secure Boot is active, and a self-built out-of-tree module like NVIDIA’s won’t have a signature the firmware trusts unless you enroll a key.

akmods automatically generates a local signing key the first time it builds a module. Import it into the Machine Owner Key (MOK) list:

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

You’ll be prompted to set a temporary password. Remember it, you’ll need it in about thirty seconds. Reboot:

sudo reboot

During the boot sequence, before the OS loads, you’ll see a blue MOK Manager screen. This is easy to miss if you’re not watching the screen — it doesn’t wait forever, and if you walk away, some firmware configurations time out and skip the enrollment silently. Select Enroll MOK, then Continue, confirm with Yes, and enter the password you set moments ago.

After the system boots, confirm the key actually enrolled:

sudo mokutil --list-enrolled

You should see your machine’s generated key alongside any existing entries. If it’s missing, the enrollment didn’t take, and you’ll need to repeat the import-reboot cycle.

Step 5: Reboot and Verify

With the module built and, if applicable, signed and enrolled, reboot normally:

sudo reboot

Once you’re back at the desktop, run the standard verification:

nvidia-smi

A correctly working install prints your GPU model, driver version, temperature, memory usage, and any running processes using the GPU. If this command isn’t found or errors out, the driver isn’t loaded — jump to the troubleshooting section below.

Double-check that X or Wayland is actually using the NVIDIA driver rather than falling back to software rendering:

glxinfo | grep "OpenGL renderer"

This should report your NVIDIA card, not “llvmpipe,” which is Mesa’s software fallback and a strong sign something upstream fell back silently.

Handling GNOME 50 and Wayland on Fedora 44

Fedora 44 made GNOME 50 Wayland-only, dropping the X11 session entirely for GNOME. This matters for NVIDIA users because historically, Wayland compositors and proprietary NVIDIA drivers have had a rocky relationship — explicit sync support, GBM buffer handling, and DRM KMS modesetting all needed maturing on NVIDIA’s side before Wayland felt genuinely stable.

The 595 driver branch that ships alongside Fedora 44 has solid explicit sync and GBM support, so most GNOME 50 Wayland sessions run cleanly out of the box. If you notice screen tearing, stuttering during window drags, or flickering in multi-monitor setups, confirm modesetting is enabled:

cat /sys/module/nvidia_drm/parameters/modeset

It should return Y. If it shows N, add the kernel parameter explicitly:

sudo grubby --update-kernel=ALL --args="nvidia-drm.modeset=1"
sudo reboot

KDE Plasma 6.6, also part of Fedora 44’s default offerings, tends to have fewer NVIDIA-related Wayland quirks than GNOME historically has, largely because KDE’s compositor (KWin) added NVIDIA-specific workarounds earlier in its development cycle. If you’re setting up a workstation and NVIDIA compatibility is a top priority, that’s worth factoring into your desktop environment choice, not just an aesthetic preference.

Legacy GPU Handling

If your card predates Pascal — think Maxwell-era GTX 900 series, Kepler, or older Quadro cards — the default 595 branch in RPM Fusion won’t support it. You need the legacy driver branch instead. Check RPM Fusion’s driver compatibility page for the exact legacy package name for your architecture, since RPM Fusion maintains separate legacy branches (typically labeled 470xx and 390xx) for older hardware. Install the matching legacy akmod package instead of the default one, and everything downstream — building, signing, verification — works identically.

This is a common trap in office environments running older workstation GPUs that got a Fedora 44 upgrade without anyone checking hardware compatibility first. If nvidia-smi fails after following every step correctly, checking whether your card actually needs the legacy branch should be one of your first troubleshooting moves.

Real-World Scenario: Production Workstation With CUDA for ML Workloads

Consider a data science workstation running Fedora 44, an RTX-class card, and PyTorch for model training. The default akmod-nvidia plus CUDA package covers driver-level GPU access, but PyTorch and CUDA toolkit versions need to align with the installed driver’s supported CUDA version.

Check the maximum supported CUDA version your driver reports:

nvidia-smi | grep "CUDA Version"

Install the matching CUDA toolkit from NVIDIA’s repository (separate from the driver package) rather than assuming the driver package alone gives you a full CUDA development environment — xorg-x11-drv-nvidia-cuda provides the runtime libraries for NVENC/NVDEC and basic CUDA execution, but serious ML development typically wants the full toolkit with nvcc and profiling tools.

sudo dnf config-manager addrepo --from-repofile=https://developer.download.nvidia.com/compute/cuda/repos/fedora44/x86_64/cuda-fedora44.repo
sudo dnf install cuda-toolkit

Verify with nvcc --version once installed, and confirm PyTorch or TensorFlow sees the GPU with a quick Python check using torch.cuda.is_available(). This two-layer setup — driver from RPM Fusion, toolkit from NVIDIA directly — is the standard pattern for ML workstations and avoids version conflicts that come from mixing driver sources.

Troubleshooting Common NVIDIA Driver Issues on Fedora 44

Black Screen After Reboot

Boot into the previous kernel from the GRUB menu (hold Shift or Esc during boot to access it), or boot into a text-only target with systemd.unit=multi-user.target appended to the kernel line temporarily. Once in, check:

journalctl -b -1 | grep -i nvidia

Look for signature verification failures (Secure Boot key not enrolled), missing module errors (build failed), or Xorg/Wayland session crashes referencing nvidia_drm.

akmod Build Fails Silently

Check the build log directly instead of guessing:

sudo cat /var/cache/akmods/nvidia/*.log 2>/dev/null | tail -50

Missing kernel headers is the most frequent culprit. Confirm they’re installed for your exact running kernel:

sudo dnf install kernel-devel-$(uname -r) kernel-headers-$(uname -r)

Then force a rebuild:

sudo akmods --force --rebuild --kernels "$(uname -r)"

“Signature verification failed” or “Key rejected” Errors

This means the module built but the running kernel refuses to load it because Secure Boot doesn’t trust the signer. Confirm which key signed the module:

modinfo -k "$(uname -r)" -F signer nvidia

If it doesn’t name your enrolled akmods key, re-run the MOK import and enrollment steps from earlier. If it still fails after a correct enrollment, the module may have been rebuilt with a new key after a previous akmods reset — re-import and re-enroll to sync them.

nvidia-smi Reports “No devices were found”

This usually means the module didn’t load at boot, even if it built successfully. Check whether it’s loaded:

lsmod | grep nvidia

If it’s absent, manually load it and check the error:

sudo modprobe nvidia

A “Key was rejected by service” error here confirms a Secure Boot signing mismatch. An “Unknown symbol” error typically points to a version mismatch between the built module and the running kernel — usually resolved by a forced akmod rebuild against the current kernel.

Screen Tearing or Stuttering on Wayland

Confirm modesetting is on (covered above), and also check whether the compositor is falling back to a suboptimal buffer path. GNOME’s Settings > About panel showing “Software rendering” instead of your GPU name is a giveaway that something upstream isn’t picking up the hardware driver correctly, often traced back to a leftover Nouveau blacklist conflict or a partial akmod build from a previous kernel version still lingering.

Driver Breaks After a Kernel Update

This shouldn’t happen with akmod-nvidia since it’s designed to rebuild automatically, but it occasionally lags behind a same-day kernel push. Force it manually after any kernel update if you’re not seeing the module rebuild:

sudo akmods --force
sudo dracut --force
sudo reboot

Building this into a habit after every dnf upgrade that touches the kernel package is cheap insurance against an unexpected black screen.

Performance, Security, and Optimization Considerations

Power management. NVIDIA’s driver includes power management daemon support (nvidia-powerd) on supported laptop GPUs. On desktop workstations running headless or under sustained load, monitor thermal and power draw with nvidia-smi -q -d POWER,TEMPERATURE rather than relying purely on nvidia-smi‘s default summary output, especially when running multi-GPU training jobs where thermal throttling on one card can silently tank overall throughput.

Firewall and permissions. The NVIDIA driver itself doesn’t open network ports, but if you’re running CUDA-accelerated services (inference servers, Jupyter with GPU kernels) that bind to network interfaces, make sure firewalld rules are scoped narrowly:

sudo firewall-cmd --list-all
sudo firewall-cmd --permanent --add-port=8888/tcp --zone=internal
sudo firewall-cmd --reload

Avoid blanket rules opening ports to the public zone on a workstation that also handles sensitive training data.

Disk I/O for driver builds. akmod builds are CPU and I/O bound but brief. On systems with slow spinning disks rather than SSDs, build times stretch noticeably, and it’s worth ensuring /var/cache/akmods isn’t sitting on a heavily fragmented or nearly-full partition, since build failures from disk space exhaustion produce confusing error messages that don’t obviously point to “you’re out of space.”

Updates and staying current. Keep RPM Fusion and the NVIDIA driver package current alongside regular Fedora updates:

sudo dnf upgrade --refresh

Resist the urge to pin an older driver version indefinitely unless you have a specific compatibility reason (an older CUDA-dependent application, for instance). NVIDIA’s driver updates frequently include security patches alongside performance fixes, and running a stale branch on a Wayland desktop that’s actively developed against newer driver features is a recipe for the exact stuttering and tearing issues covered above.

Removal, if you ever need it. Clean removal matters if you’re switching GPUs or troubleshooting a persistent conflict:

sudo dnf remove 'akmod-nvidia*' 'kmod-nvidia*' 'xorg-x11-drv-nvidia*'
sudo dracut --force
sudo reboot

This drops you back to Nouveau cleanly without leftover module conflicts.