Every time a new Ubuntu LTS drops, the same forum threads reappear within a week: black screens after reboot, GNOME Shell crashing back to the login page, “NVIDIA-SMI has failed because it couldn’t communicate with the NVIDIA driver,” and the classic Secure Boot lockout that leaves people convinced their GPU died overnight. It didn’t die. The kernel module just isn’t loading, and there’s almost always a boring, fixable reason why.

Ubuntu 26.04 LTS, codenamed Resolute Raccoon, changes the equation slightly compared to previous releases. It ships with the Linux 7.0 kernel, GNOME 50, and it’s the first LTS to go fully Wayland by default, dropping the Xorg session entirely for most stock configurations. That last point matters more than people realize, because a good chunk of legacy Nvidia troubleshooting advice floating around the internet was written for an Xorg-centric world. If you’ve been running 22.04 or 24.04 on a workstation with an RTX card and you’re about to jump to 26.04, some of your old muscle memory is going to be wrong, and that’s precisely where this guide earns its keep.

This walkthrough is written the way I’d actually do it on a client machine or a GPU compute node: verify hardware first, pick the right driver channel, handle Secure Boot properly instead of just disabling it out of laziness, and build in verification steps so you’re not guessing whether the install actually worked. Whether you’re setting up a gaming desktop, a CUDA development box, or a headless server doing inference workloads, the fundamentals below apply. The differences show up mostly in which package you choose, not the process itself.

One quick note before diving in: Ubuntu 26.04.1, the first point release, landed on August 29, 2026, and that’s the version most people should be installing today rather than the original April GA image. Point releases bundle hardware enablement fixes that matter a lot for Nvidia users, so if you’re doing a fresh install, grab the .1 ISO.

Before You Touch the Terminal: Pre-Flight Checks

Skipping this section is how people end up filing bug reports against Nvidia when the actual problem is a BIOS setting or a leftover kernel module from a previous install attempt.

Confirm your GPU is actually detected

lspci -k | grep -A 3 -i vga

You want to see your Nvidia card listed with the current kernel driver in use, most likely nouveau on a fresh install. If nothing shows up here, that’s a hardware or BIOS-level problem (PCIe slot, riser cable, or a dead card), and no amount of driver wrangling will fix it. I’ve lost an embarrassing number of hours in the past chasing driver bugs that turned out to be a poorly seated GPU riser in a rack server.

Check kernel version and Secure Boot state

uname -r
mokutil --sb-state

Ubuntu 26.04 defaults to the 7.0 kernel line, and Nvidia’s driver packages in the Ubuntu repos are built and tested against it, so you generally don’t need to worry about DKMS compilation failures the way you sometimes do on rolling-release distros. Secure Boot status matters because it determines whether you’ll be walked through the MOK (Machine Owner Key) enrollment screen during install. If mokutil returns “SecureBoot enabled,” expect an extra reboot step later. Don’t disable Secure Boot just to skip it, that’s a real security regression for very little convenience gained.

Remove any leftover Nvidia packages from a previous attempt

sudo apt purge '^nvidia-.*' '^libnvidia-.*'
sudo apt autoremove
sudo apt update

This step catches more problems than people expect. Partial installs, mismatched versions from PPAs, and residual DKMS builds are the single most common cause of “the driver won’t load” tickets I’ve triaged. Start clean.

Method 1: The ubuntu-drivers Tool (Recommended for Almost Everyone)

Canonical’s ubuntu-drivers utility remains the sanest default path on 26.04, and it’s the one I recommend to clients unless they have a specific reason to deviate, such as needing a particular CUDA toolkit version pinned to an exact driver release.

Step 1: List available drivers for your hardware

sudo ubuntu-drivers devices

This queries Nvidia’s hardware database against your detected GPU and shows every compatible driver branch, flagging the recommended one. On 26.04, expect to see the 580-series branch as the current recommended proprietary driver for most modern GeForce and Quadro/RTX Professional cards, alongside older branches for legacy hardware.

Step 2: Install the recommended driver

sudo ubuntu-drivers install

Note that autoinstall still works as an alias but is technically the older invocation; install is the current preferred syntax and behaves identically for a first-time setup, while also handling upgrades cleanly on systems that already have a driver installed. The tool pulls in the correct nvidia-driver-XXX metapackage along with nvidia-dkms-XXX, kernel headers, and the necessary libGL and Vulkan libraries.

Step 3: If prompted, enroll the MOK key

On Secure Boot systems, apt will pause mid-install and show a blue-screen dialog asking you to set a MOK enrollment password. Set one you’ll remember for the next thirty seconds, then:

sudo reboot

On boot, you’ll hit the “MOK Management” screen. Select Enroll MOK, enter the password you just set, confirm, and let the system continue booting normally. This step signs the Nvidia kernel module with a key the firmware trusts, which is the correct way to run proprietary drivers under Secure Boot rather than disabling the protection wholesale.

Step 4: Reboot and verify

sudo reboot

After the reboot, confirm the driver actually loaded:

nvidia-smi

You should see a table with driver version, CUDA version, GPU name, temperature, and memory usage. If this command hangs, errors out, or returns “command not found,” skip ahead to the troubleshooting section, because something in the chain above didn’t complete.

Method 2: Manual Package Install (When You Need Precision)

Sometimes autoinstall picks a driver branch that’s newer than what your CUDA toolkit or a specific application supports. In production GPU compute environments, this is common enough that I almost never let a server autoinstall; I pin the exact version.

First, check what’s available in the repos:

apt-cache search nvidia-driver | grep -E "^nvidia-driver-[0-9]"

Install a specific branch explicitly:

sudo apt install nvidia-driver-580 nvidia-dkms-580

For headless or server deployments running compute workloads without a display server at all, use the server-tuned driver package instead, which strips out the desktop GL stack you don’t need:

sudo ubuntu-drivers list --gpgpu
sudo ubuntu-drivers install --gpgpu

This distinction between desktop drivers and gpgpu/server drivers trips up a surprising number of people setting up their first CUDA training rig. Installing the desktop metapackage on a headless box isn’t fatal, but it pulls in Xorg dependencies you’ll never use and adds unnecessary attack surface on a machine that shouldn’t have a display stack running at all.

Wayland Changes Things: What’s Different on 26.04

Since GNOME 50 on Ubuntu 26.04 runs Wayland exclusively by default, the old workarounds involving /etc/X11/xorg.conf tweaks for multi-monitor setups or forced modesetting are largely irrelevant now. Nvidia’s driver has matured its Wayland support substantially over the past several release cycles, but there are still a couple of practical wrinkles worth knowing about.

GBM and explicit sync

Modern Nvidia drivers (535 and later) support the GBM (Generic Buffer Management) API required for proper Wayland compositing, and the 570+ branches added explicit sync support that resolved a lot of the stuttering and tearing complaints that plagued earlier Nvidia-on-Wayland setups. If you’re on 26.04 and still seeing visual artifacts or flickering, confirm you’re on at least the 570 branch:

nvidia-smi --query-gpu=driver_version --format=csv

Forcing Xorg as a fallback

If a specific application genuinely doesn’t play nice with Wayland yet (some older CAD or CAM software, certain screen recording tools, or proprietary remote desktop clients), you can still select “Ubuntu on Xorg” from the gear icon on the GDM login screen, provided the Xorg session packages are installed:

sudo apt install ubuntu-session

This isn’t removed from 26.04, just no longer the default. Keep it around if your workflow has any legacy dependencies you haven’t fully migrated yet.

Verifying a Healthy Install: Don’t Just Trust nvidia-smi

nvidia-smi returning clean output is a good sign but it’s not the whole picture. I always run a few more checks before calling an install done, especially on machines that will run sustained workloads.

Check that the kernel module is actually the one loaded, not nouveau sneaking back in:

lsmod | grep nvidia
lsmod | grep nouveau

You want output for the first command and nothing for the second. If nouveau is still loaded alongside the Nvidia module, you’ll get instability, particularly under load, because the two drivers fight over the same hardware.

For OpenGL rendering verification on desktop systems:

glxinfo | grep "OpenGL renderer"

It should report your Nvidia GPU by name, not “llvmpipe” (software rendering) or “NVIDIA… via nouveau.” Seeing llvmpipe here after a “successful” install is one of the most common false-positive scenarios, because the system boots fine and looks normal, it’s just rendering everything on the CPU.

For Vulkan support, relevant for gaming and some compute frameworks:

vulkaninfo --summary

Troubleshooting: The Errors You’ll Actually Hit

Black screen or login loop after reboot

This is almost always a Secure Boot signing failure or a nouveau/nvidia module conflict. Boot into recovery mode from the GRUB menu, drop to a root shell, and check:

dmesg | grep -i nvidia
journalctl -b -1 | grep -i nvidia

If you see “Failed to load module” errors referencing signature verification, the MOK enrollment didn’t complete. Re-run the enrollment:

sudo mokutil --import /var/lib/shim-signed/mok/MOK.der
sudo reboot

Then enroll again at the blue screen exactly as before.

“NVIDIA-SMI has failed because it couldn’t communicate with the NVIDIA driver”

This message almost always means the kernel module isn’t loaded, usually because DKMS failed to build it against your current kernel. Check the build log:

sudo dkms status
sudo apt install --reinstall nvidia-dkms-580

If you recently ran a kernel update via apt upgrade without rebooting, this is the culprit nine times out of ten. DKMS needs to rebuild the module for the new kernel, and that rebuild only triggers correctly after a reboot into the new kernel followed by a driver reinstall or a dkms autoinstall.

Nouveau keeps loading despite blacklisting

Blacklist files alone don’t always take effect immediately because initramfs needs regenerating:

echo -e "blacklist nouveau\noptions nouveau modeset=0" | sudo tee /etc/modprobe.d/blacklist-nouveau.conf
sudo update-initramfs -u -k all
sudo reboot

The -k all flag regenerates initramfs for every installed kernel on the system, not just the currently running one, which matters if you’ve got multiple kernel versions hanging around from previous updates.

GPU not detected in a VM or container

If you’re passing through a GPU to a KVM guest or working inside an LXC/Docker container, nvidia-smi failing usually points to missing IOMMU configuration on the host or a missing NVIDIA Container Toolkit setup rather than a driver problem on the guest itself. Confirm IOMMU is enabled:

dmesg | grep -e DMAR -e IOMMU

And for containerized workloads, verify the toolkit is correctly registered with the Docker daemon:

nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Driver installs fine but performance is poor

Check the GPU’s power state and persistence mode, particularly on servers where the card might be idling in a low-power state between jobs:

nvidia-smi -pm 1
nvidia-smi --query-gpu=power.draw,clocks.sm,pstate --format=csv

Persistence mode keeps the driver loaded even when no application is actively using the GPU, which avoids the initialization latency hit on every new job launch. This is a two-second fix that gets overlooked constantly on compute nodes.

Performance, Security, and Production Considerations

A driver install that “works” isn’t the same as one that’s production-ready. A few things worth building into your standard operating procedure.

Pin your driver version in production. Letting apt upgrade silently bump your Nvidia driver on a server running CUDA workloads is asking for a bad afternoon when a CUDA toolkit version suddenly mismatches. Use apt-mark hold:

sudo apt-mark hold nvidia-driver-580 nvidia-dkms-580

Monitor GPU health continuously, not just at install time. Tools like nvtop give you an htop-style live view of GPU utilization, memory, and temperature, and it’s far more useful for day-to-day monitoring than repeatedly calling nvidia-smi.

sudo apt install nvtop

Set power limits on shared or thermally constrained systems. If you’re running GPUs in a dense rack environment where cooling is marginal, capping power draw prevents thermal throttling from tanking performance unpredictably:

sudo nvidia-smi -pl 250

Firewall and access considerations for GPU compute nodes. If the box exposes any remote management or job-scheduling interface (Jupyter, a training dashboard, or a Ray cluster head node), don’t rely on the application’s own auth alone. Lock it down at the network layer too:

sudo ufw allow from 10.0.0.0/24 to any port 8888
sudo ufw enable

Keep firmware updated alongside the driver. GPU firmware bugs occasionally cause instability that looks exactly like a driver problem. Check for updates through fwupdmgr:

sudo fwupdmgr refresh
sudo fwupdmgr get-updates