Blackwell GPUs on Proxmox 9.1: When Open Nvidia Drivers Won't Load

Some frustration only shows up when everything should work. You've got the hardware seated properly and the BIOS looks clean. Secure Boot is off, Nouveau is blacklisted, and the installer finishes with the progress bar at 100 percent. For a brief moment, you think you're done. Then Proxmox drops the hammer: unable to load the kernel module.

A lot of people have hit that moment recently after dropping Nvidia's new Blackwell-based GPUs, like the 5060 and 5060 Ti, into Proxmox 9.1 systems. On paper, this is supposed to be the easy era. Nvidia now offers "open" kernel modules, Proxmox documents which driver versions to use, and kernel regressions are supposedly understood. And yet, here we are, staring at nvidia.ko refusing to exist. Too many people are reporting it for this to be one person missing a step.

The promise of "open" Nvidia drivers

Blackwell GPUs arrived with a small but important shift. Nvidia's newer cards lean heavily on the MIT/GPL "open" kernel driver path instead of the classic proprietary module that Linux users have wrestled with for years.

In theory, this should be a win, with better kernel compatibility, fewer DKMS headaches, and less friction when kernels move fast, which Proxmox kernels absolutely do.

To be fair, plenty of people are running 50-series cards just fine. Some are even doing it on newer kernels than Proxmox officially blesses, with the same drivers, the same installer, and the same MIT/GPL option selected. That's what makes the failures so confusing.

When "supported" doesn't mean "working"

In the cases that keep popping up, the story usually looks the same. Someone has a fresh Proxmox 9.1 install, a Blackwell GPU, and Nvidia's recommended 580-series driver runfile. The installer completes without obvious errors, and then the module refuses to load.

modprobe nvidia comes back with nothing helpful. lsmod shows no nouveau, no nvidia, and nothing competing for the device. The logs, however, tell a more ominous story:

request_mem_region failed for 64M @ 0xd0000000

That line is the villain here. It usually points to another driver already owning the GPU's memory region. Nouveau is the usual suspect, but in these setups it's already blacklisted and gone from initramfs. Secure Boot is disabled, and there's no rivatv relic lurking in the background. Still, the Nvidia driver probes the device and bounces off.

At that point, the installer helpfully suggests the usual causes (wrong kernel headers, a mismatched GCC version, an unsupported GPU), none of which actually explain what's happening.

Kernel roulette doesn't always save you

One of the first instincts is to blame the kernel. Proxmox itself flags issues with newer kernel branches, and many users immediately downgrade from 6.17 to 6.14. That works for some people, and for others nothing changes.

The driver compiles against the correct kernel, and the headers match. The system is definitely booted into the same kernel version it built against. And yet, /lib/modules/$(uname -r) never gets a usable nvidia.ko.

This is where the experience turns from "Linux troubleshooting" into something more existential. You've checked every box and followed the docs, and the system agrees with you on every factual point but still refuses to cooperate.

VFIO complicates things more than it should

Dig a little deeper into the logs and another clue keeps popping up: VFIO messages interleaved with Nvidia's failures, and that matters.

A lot of Proxmox users aren't installing Nvidia drivers just for display. They want GPU sharing for containers, CUDA workloads, or passthrough experiments. VFIO gets involved early, and in some setups it looks like it's claiming parts of the device before the Nvidia driver ever gets a fair shot.

Even when you're not explicitly passing the GPU through to a VM, Proxmox's configuration and boot order can put VFIO in the driver race earlier than expected. The result is a bizarre stalemate where nothing appears to own the GPU, but the Nvidia driver still can't claim its memory regions.

The MIT/GPL choice isn't optional anymore

One thing is clear: Blackwell cards simply won't work with the old proprietary kernel module. If you're not selecting the MIT/GPL option during installation, you're dead in the water.

Most people in this situation are selecting it correctly. The installer prompts them, they choose the open driver, and it still fails. That's important, because it rules out the most obvious mistake and shows how narrow the problem space actually is.

Why some systems work and others don't

This is where the conversation gets uncomfortable. People with nearly identical setups, down to the GPU, the Proxmox version, and the driver build, report wildly different outcomes. One machine boots clean with CUDA available, and another hits the same kernel error every time.

The difference often comes down to system history. Long-lived Proxmox hosts with years of kernel upgrades, hardware swaps, and leftover configuration files seem more likely to hit these issues, and fresh installs behave better. That doesn't hold every time, but it holds often enough to notice the pattern.

It's not a satisfying answer, but it's a familiar one. Linux systems accumulate state. Initramfs hooks, modprobe configs, and bootloader fragments stick around long after their original purpose is gone, and eventually a new GPU shows up and trips over something invisible.

The reinstall nobody wants to do

Several people who hit this wall eventually admit the same thing: the system probably needs a clean reinstall. Proxmox isn't broken, and Nvidia's drivers aren't unusable. The interaction between fast-moving kernels, VFIO, and Nvidia's transition to open modules just leaves very little margin for historical cruft.

That's a brutal conclusion for a hypervisor. Proxmox machines aren't laptops you casually wipe on a Sunday afternoon. They run storage, VMs, networks, and workloads that took years to shape. And yet, for some Blackwell users, a reinstall is the only thing that finally makes modprobe nvidia stop complaining.

This is the cost of living on the edge

None of this means Blackwell GPUs are a bad choice for Proxmox. Once they work, they seem to work well. Multi-GPU setups mixing 30-series, 40-series, and 50-series cards are out there, running inference jobs and container workloads without issue.

It does mean the "open driver" era hasn't magically erased the complexity of Nvidia on Linux. The pain points have moved around, and they're all still there. Proxmox moves fast, and kernels move faster. Nvidia is mid-transition between driver models, and VFIO is powerful but unforgiving. Stack those together and you get exactly this kind of failure, silent, confusing, and deeply annoying.

Where this leaves Proxmox users

If you're planning to drop a Blackwell GPU into a Proxmox 9.1 host, you can do it, but go in with your eyes open. Start clean if you can, be deliberate about VFIO configuration, and double-check which kernel you're actually booting. Expect that the installer finishing successfully doesn't mean the driver will load.

If you hit that dreaded kernel module error after doing everything right, don't assume you're missing something obvious. Sometimes the system really is just tangled. That comes with running brand-new hardware on a hypervisor that's sprinting forward alongside it: the future shows up early, but it doesn't always arrive politely.