When Your Kernel Upgrades, Don’t Let DKMS Leave You Stranded

Technical Briefing | 10/22/2026

You’ve installed a custom kernel module — maybe it’s the NVIDIA driver for your GPU, a specialized network card module, or perhaps ZFS on Linux. You’ve used DKMS, felt good about it, and then mostly forgotten about it. That’s the idea, right? DKMS is supposed to automatically rebuild these modules against new kernels, so you can just `apt upgrade` or `dnf update` and reboot without a second thought. But then you reboot, your monitor is running at a weird resolution, or your ZFS pools aren’t showing up, and suddenly that ‘automatic’ process feels like a bad joke. I’ve seen this silently fail on production boxes, leaving systems limping along or, worse, just plain broken.

The Promise and Pain of Automatic Rebuilds

The theory behind DKMS is solid: register your module, and it’ll handle the dirty work of compiling it whenever a new kernel version lands. This saves you from having to manually track kernel versions, download headers, and run `make` every time there’s an update. It’s brilliant when it works. But the real-world catches are subtle. Maybe a dependency changed, maybe your kernel headers weren’t installed correctly for the new kernel, or maybe the module’s own build system had a hiccup. The most annoying part? Unless you’re explicitly watching the upgrade logs, you often won’t know it failed until you’ve rebooted and something important isn’t working right.

Peering into the DKMS Black Box

When things feel off, your first stop is always the `dkms` command itself. It’s got a pretty good `status` subcommand that’ll give you a quick overview of what modules DKMS knows about, and against which kernel versions they’re currently built. This is where you’ll spot unbuilt modules or ones listed as ‘invalid.’ But just seeing ‘invalid’ isn’t enough; we need to know *why*.

dkms status
dkms autoinstall
cat /var/lib/dkms/<module_name>/<module_version>/build/make.log

That `dkms status` output is your immediate diagnostic. If you see a module showing `installed` for the *old* kernel but `not built` or `not installed` for your *current* running kernel (which you can check with `uname -r`), you’ve found your problem. And then there’s that `make.log` path. Most tutorials skip this part, but it’s where the real errors lie. It’s a standard `make` output, so you’re looking for compilation errors — missing headers, incompatible kernel APIs, whatever tripped up the build process. Sometimes, just running `dkms autoinstall` will kickstart the process if it was merely missed during the upgrade, but if there’s a compilation error, it’ll just fail again, and the log is still your key.

Cleaning Up The Old Gunk

Over time, especially if you’ve had a few upgrade failures, your `dkms` tree can get cluttered with old, unneeded kernel module builds or even partially broken ones. This doesn’t usually hurt anything, but it can make `dkms status` output noisy and might even consume disk space you’d rather have. Cleaning it up is straightforward and keeps your system tidy.

• First, list all installed kernel images that aren’t the current one. Remove any old kernels you no longer need. This often removes associated DKMS builds automatically.
• Use `dkms remove <module>/<version> –all` to prune all versions of a specific module. Then, `dkms install <module>/<version>` to rebuild and reinstall only for your current kernel.
• If a specific build for an old kernel is causing issues, you can surgically remove it: `dkms remove <module>/<version> -k <kernel_version>`.

Don’t let DKMS become another mystery box. Knowing how to check its pulse and read its tea leaves — those log files — will save you from a lot of head-scratching when your custom drivers decide to take an unscheduled holiday. It’s not about babysitting, it’s about being prepared when the ‘automatic’ part inevitably hits a snag. So next time you update a kernel, give `dkms status` a quick peek afterward, before that crucial reboot. You’ll thank yourself.