Why this matters beyond the homelab: GPU passthrough failures have a habit of looking like host-level problems even when they aren’t. This one resolved cleanly because the two layers, host and guest, were checked independently instead of assumed to be the same failure.
The setup
Tantive-III is a Docker host VM on Node-A (FCM2250), with an RTX 4000 SFF Ada passed through via vfio-pci (PCI 02:00.0/02:00.1). A routine update to the guest’s kernel left GPU passthrough broken. nvidia-smi inside the VM had nothing to say.
Ruling out the host first
The vfio-pci binding on the Proxmox host was the first thing to check, since a broken passthrough after any kind of update is the classic symptom of the host losing its grip on the device. It hadn’t. The binding on 02:00.0/02:00.1 was fully intact, confirmed directly against the host, unaffected by whatever had changed in the guest. That ruled out an entire category of fix before wasting time on it.
The actual cause
The problem was upstream of the driver entirely: the kernel had updated to 6.12.107+deb13-amd64, and the matching linux-headers package for that exact kernel version hadn’t been installed. Headers existed going back through six older kernel versions, 6.12.73 through 6.12.96, just not for the one currently running. Without matching headers, dkms has nothing to build the nvidia module against, so nvidia-current sat unbuilt for a kernel it had never seen.
Installing linux-headers-6.12.107+deb13-amd64 triggered the dkms postinst hook automatically. All five nvidia modules, nvidia, nvidia-modeset, nvidia-drm, nvidia-uvm, nvidia-peermem, built and signed against the running kernel without any further intervention. nvidia-smi came back clean afterward: driver 550.163.01, CUDA 12.4.
A pattern, not a one-off
This isn’t the first time this exact gap has shown up on this node. Kernel updates are outpacing linux-headers availability in the repo, which means the module goes unbuilt every time until someone notices and installs the matching headers by hand. The host-side vfio-pci layer has never been the problem in any of these incidents. It’s always the guest-side dkms build, waiting on a package that hasn’t caught up yet.
The lesson
Two fixes worth setting up before this happens a third time: either hold the kernel package to stop it from updating ahead of the headers repo, or add an apt postinst hook that checks for and installs matching headers automatically on every kernel update. Either one turns this from a recurring manual fix into a non-event. Also worth a note in passing: the card was running at 71°C at idle with the fan at 79%, which isn’t a failure but is worth keeping an eye on for airflow and dust in that chassis.
Update, October 2026
It happened again. The guest moved to kernel 6.12.111+deb13-amd64, the matching headers weren’t yet in the repository, and the nvidia module sat unbuilt, exactly as before. This time the plan treated it as a gate: no reboot of the host until the guest’s dkms status showed the module built against the running kernel and nvidia-smi answered. Rebooting early would have taken the GPU, the AI stack, and the monitoring hub down together.
On October 9 the headers were published. Installing linux-headers-6.12.111+deb13-amd64 triggered the dkms autoinstall, nvidia-current rebuilt at 550.163.01, and nvidia-smi came back healthy. The host-side vfio-pci binding was, once again, never the problem. A recurrence is the best argument for the two fixes in the lesson above: either pin the kernel ahead of the headers repository, or add a hook that checks for matching headers on every kernel update.