Why NVIDIA driver installation fails on Ubuntu, and how to fix it
modprobe: ERROR: could not insert 'nvidia': Key was rejected by service
Also appears as
- Failed to load module nvidia (module not found)
- dpkg: error processing package nvidia-driver-535 (--configure)
Short answer
The single most common reason NVIDIA driver installation fails on Ubuntu is Secure Boot rejecting the unsigned or self-signed kernel module at load time, since most machines now ship with Secure Boot enabled out of the box. The fix is enrolling the MOK key the installer generates, or disabling Secure Boot in the BIOS, then clearing any lingering nouveau or mixed-install conflicts before rebooting.
Affects: Fresh Ubuntu installs on hardware shipped with Secure Boot enabled by default, and any machine mixing apt-installed and runfile-installed NVIDIA drivers.
Fastest path to a working driver install
- 1Check Secure Boot status: mokutil --sb-state. If enabled, this is very likely your root cause.
- 2Purge any previous partial or conflicting driver install: sudo apt purge '^nvidia-.*' before reinstalling cleanly.
- 3Blacklist nouveau and update the initramfs so it does not conflict with the new driver.
- 4Install the recommended driver: sudo ubuntu-drivers autoinstall, or a specific version with sudo apt install nvidia-driver-550.
- 5Reboot, and if prompted by Secure Boot MOK enrollment, complete it with the password you set during install.
- 6Verify with nvidia-smi after reboot.
How to confirm this is your problem
- modprobe error stating the nvidia module key was rejected by the service
- dpkg reports an error configuring the nvidia-driver package during install
- nvidia-smi fails immediately after what appeared to be a successful apt install
- Ubuntu boots into a low-resolution fallback graphics mode after driver install
Root causes and fixes
Secure Boot is enabled and rejects the unsigned kernel module
Most Ubuntu installs since recent LTS releases enable UEFI Secure Boot by default. The NVIDIA driver installer generates its own MOK (Machine Owner Key) to self-sign the kernel module, but this key must be explicitly enrolled into the firmware's trusted key database through a reboot-time prompt. Skipping or missing that prompt leaves the module permanently rejected on every subsequent load attempt.
Fix: Run mokutil --import to enroll the MOK key generated during driver install, reboot, and complete the blue MOK Manager enrollment screen using the password you set, or disable Secure Boot in the BIOS if acceptable for your environment.
mokutil --sb-state sudo mokutil --import /var/lib/shim-signed/mok/MOK.der sudo reboot
The nouveau open-source driver is still loaded and conflicting
Ubuntu loads nouveau by default for basic display output before any proprietary driver is installed. If the blacklist and initramfs rebuild steps are skipped or done in the wrong order relative to the driver install, nouveau can still claim the GPU device at boot, preventing the new nvidia module from binding to the hardware.
Fix: Blacklist nouveau explicitly and rebuild the initramfs before rebooting, rather than relying on the driver installer to handle this automatically.
echo 'blacklist nouveau' | sudo tee /etc/modprobe.d/blacklist-nouveau.conf echo 'options nouveau modeset=0' | sudo tee -a /etc/modprobe.d/blacklist-nouveau.conf sudo update-initramfs -u
Kernel headers missing or mismatched, so DKMS cannot build the module
The NVIDIA driver package relies on DKMS to compile the kernel module against the exact running kernel's headers. If linux-headers for the currently running kernel are not installed, or a kernel update happened without a corresponding headers update, the DKMS build step fails silently or with a cryptic compiler error during dpkg configuration.
Fix: Install the exact matching headers package for your running kernel before installing or reinstalling the driver.
sudo apt install linux-headers-$(uname -r) sudo dkms autoinstall
Mixing apt-based and runfile-based driver installation methods
Some guides recommend the .run installer while others recommend apt; using both on the same machine, or switching methods without fully purging the previous install, leaves conflicting files, kernel module versions, and package manager state that neither installer fully cleans up, causing unpredictable configuration failures.
Fix: Pick one installation method (apt is generally easier to maintain and update on Ubuntu) and fully purge any remnants of the other before reinstalling from scratch.
sudo apt purge '^nvidia-.*' sudo apt autoremove
Driver version does not yet support a very new kernel
Immediately after a new Ubuntu release or a bleeding-edge kernel upgrade, the NVIDIA driver's DKMS build scripts may not yet have compatibility patches for that kernel's internal API changes, causing the module build to fail with kernel-symbol-related compiler errors regardless of headers being correctly installed.
Fix: Check NVIDIA's release notes or community reports for known kernel compatibility issues, and either pin to an older, well-supported kernel temporarily or wait for a driver point release that adds support.
Diagnostic commands
Check Secure Boot state first
mokutil --sb-state
SecureBoot enabled combined with a rejected key error is the most common root cause; if disabled, look elsewhere for the failure.
Check the kernel log for the specific module load rejection reason
dmesg | grep -i nvidia
Look for 'Key was rejected' (Secure Boot), 'Unknown symbol' (kernel headers mismatch), or no mention at all (module never attempted to load, likely nouveau conflict).
Confirm nouveau is not still bound to the GPU
lsmod | grep nouveau
Any output means nouveau is loaded and must be blacklisted with an initramfs rebuild before the nvidia module can take over the device.
Confirm kernel headers match the running kernel exactly
dpkg -l | grep linux-headers-$(uname -r)
No matching line means DKMS cannot build the module for the currently running kernel; install the exact matching headers package.
Stopping it from happening again
- Bake Secure Boot MOK enrollment and driver installation into your golden image so new machines never hit this manually.
- Standardize on one installation method (apt) across your fleet rather than mixing apt and runfile installs.
- Pin kernel and driver versions together, and test any kernel upgrade on a canary machine before rolling it out fleet-wide.
- Document your organization's Secure Boot policy so new engineers are not surprised by the MOK enrollment step on first setup.
When this becomes an architecture problem
If this happens across every new machine in a rollout, or your security policy mandates Secure Boot in a way that complicates unsigned module workarounds, treat it as a provisioning and imaging problem to solve once centrally rather than a recurring per-machine fix.
Frequently asked questions
Why does my NVIDIA driver install fail specifically on Ubuntu but not other distros?
It is not unique to Ubuntu; any distro with Secure Boot enabled by default and no automatic MOK enrollment flow hits the same class of failure. Ubuntu is simply the most common distro engineers hit this on because it enables Secure Boot out of the box on most fresh installs and desktop images.
What is a MOK key and why do I need to enroll it?
MOK stands for Machine Owner Key. Since the proprietary NVIDIA driver is not signed by a key Microsoft or the distro trusts by default, the installer generates its own key and self-signs the kernel module with it. Secure Boot only allows this module to load once you explicitly enroll that key into the firmware's trusted database, which requires a reboot-time confirmation step.
Is it safe to just disable Secure Boot instead of enrolling the key?
For most workstations and lab machines, yes, disabling Secure Boot is a simpler and equally functional fix. In regulated or compliance-driven environments, however, Secure Boot is often a required control, in which case enrolling the MOK key is the correct approach since it preserves Secure Boot protection while allowing the signed driver module to load.
I purged and reinstalled the driver and it still fails the same way. What next?
Check dmesg immediately after the failed load attempt rather than repeating the purge-and-reinstall cycle. The specific rejection reason in the kernel log, whether it names Secure Boot, an unknown symbol, or nouveau, tells you which of the underlying causes actually applies to your machine.
Size it properly next time
Free calculators that prevent this class of failure before you provision hardware.
On-Prem AI Deployment Checklist
A 30-point pre-deployment checklist covering use cases, hardware, security, model operations, and rollout for self-hosted enterprise LLMs.
Free ToolAir-Gapped LLM Deployment Checklist
A practical control checklist for deploying and maintaining large language models in a fully air-gapped environment, from initial staging through ongoing patching and drift detection.
Free ToolSelf-Hosted LLM Hardware Estimator
Estimate the VRAM footprint, GPU count, and hardware budget required to self-host an open-weight LLM with your concurrency and context needs.
Related problems
nvidia-smi command not found or fails to communicate with the driver
nvidia-smi not found or unable to communicate almost always means the NVIDIA kernel module never loaded, and the two most common reasons are that the driver was never installed, or the driver is installed but Secure Boot is blocking the unsigned kernel module from loading. WSL2 users hit a different variant: the driver must be installed on the Windows host, never inside the Linux guest.
CUDA version mismatch between PyTorch and the system driver
PyTorch ships its own bundled CUDA runtime inside the wheel, so it never uses your system's CUDA toolkit (the one nvcc reports). The only number that matters is the driver's maximum supported CUDA version, shown top right in nvidia-smi output. Fix the mismatch by installing a torch wheel built for a CUDA version at or below that number, not by touching nvcc or the toolkit.
torch.cuda.is_available() returns False even though a GPU is present
torch.cuda.is_available() returning False almost always means either the installed torch wheel is a CPU-only build, or the process cannot see the GPU due to a driver, container, or environment variable problem. Checking torch.version.cuda for None immediately tells you whether you have a CPU-only wheel, which is the single most common cause and the fastest thing to rule out.
cuDNN version mismatch or library loading error in PyTorch
PyTorch wheels bundle their own cuDNN version internally, so a separately installed system-wide cuDNN is usually unnecessary and often the actual cause of this error. When LD_LIBRARY_PATH exposes a different cuDNN version than the one torch was compiled against, torch loads the wrong one at runtime and throws a version incompatibility error. Removing the manual cuDNN path and letting torch use its bundled copy resolves most cases.
GuideOn-Prem LLM Inference Hardware in 2026: A Roundup
On-prem LLM inference hardware for 2026: H100 vs H200 vs B200 pricing, when A100 fleets still work, and how to size GPUs against real serving needs.
GuideOn-Prem GPU Cluster Design: Node Sizing, Networking, and Storage
Design an on-prem GPU cluster: node sizing for H100/H200/B200, InfiniBand vs RoCE networking, storage throughput, and rack power for enterprise AI workloads.
Still stuck, or tired of fighting your own infrastructure?
Netray deploys and operates on-prem AI for regulated manufacturers and defense suppliers. We have debugged this stack in production, on air-gapped networks, at scale.