Most drivers are in the kernel and are built with it. A few are not, and those have to be compiled against every kernel you install. DKMS is what does that automatically, and knowing how it works is the difference between a routine update and a machine that boots to a black screen.

Why out-of-tree modules exist

Licensing. ZFS is CDDL and cannot be merged into a GPLv2 kernel. NVIDIA’s driver is proprietary.

Vendor cadence. Some vendors ship drivers faster than the kernel release cycle.

Niche hardware. Not everything is worth carrying in mainline.

The consequence is the same in every case: the module must be rebuilt for each kernel, because kernel internal APIs are not stable across versions by design.

What DKMS does

It keeps the module source in /usr/src, registers which kernels it should build for, and hooks into your package manager so that installing a kernel triggers a rebuild.

dkms status
# nvidia/560.35.03, 6.18.44, x86_64: installed
# zfs/2.4.4, 6.18.44, x86_64: installed

That output is the single most useful command here. It lists every module and the kernels it is currently installed for.

The habit that prevents disasters

After a kernel update and before rebooting, check that the modules built:

dkms status

If your new kernel is not listed alongside the module, it will not be there when you reboot. Fixing it now takes a minute. Fixing it after rebooting into a system with no graphics driver takes considerably longer.

This is the single most valuable operational habit for anyone running NVIDIA, VirtualBox, or ZFS, and it is why both our NVIDIA drivers and ZFS guides say the same thing.

Why builds fail

Missing kernel headers, by a wide margin the most common:

sudo apt install linux-headers-$(uname -r)          # Debian and Ubuntu
sudo dnf install kernel-devel-$(uname -r)           # Fedora
sudo pacman -S linux-headers                        # Arch

Note that you need headers matching the new kernel, not the running one, so installing the metapackage that tracks your kernel series is the reliable arrangement:

sudo apt install linux-headers-generic

Source too old for the kernel. Kernel internals change and a module written against 6.12 may not compile against 7.2. The fix is a newer version of the module, not a workaround. This is exactly why OpenZFS publishes a supported kernel range.

Full /boot. A successful module build still needs the initramfs written. A full boot partition produces a truncated image, which is worse than a failed build.

df -h /boot

Repairing a failed build

# See what went wrong
sudo dkms autoinstall
cat /var/lib/dkms/nvidia/560.35.03/build/make.log

# Rebuild everything for the running kernel
sudo dkms autoinstall

# Target one module and kernel
sudo dkms install -m nvidia -v 560.35.03 -k 6.18.44

# Remove and re-add
sudo dkms remove -m nvidia -v 560.35.03 --all
sudo dkms add -m nvidia -v 560.35.03
sudo dkms build -m nvidia -v 560.35.03
sudo dkms install -m nvidia -v 560.35.03

The make.log is where the actual compiler error lives, and it is almost always more informative than the summary DKMS prints.

If you have already rebooted into a broken system, boot the previous kernel from the GRUB menu and repair from there.

Secure Boot

A module can build perfectly and still refuse to load:

mokutil --sb-state
sudo dmesg | grep -i 'module verification\|signature'

With Secure Boot on, unsigned modules are rejected. Either enrol a machine owner key and configure DKMS to sign automatically, which Ubuntu prompts you through, or disable Secure Boot. Our Secure Boot explainer covers the tradeoff.

Reducing exposure

Fewer out-of-tree modules means fewer things that can break.

Prefer in-tree alternatives where they are adequate: the open NVIDIA kernel modules over the fully proprietary ones on supported hardware, and Btrfs over ZFS if snapshots are all you need. Every module you remove from DKMS is one that cannot fail on a kernel update.

Frequently Asked Questions

What is DKMS?

Dynamic Kernel Module Support. It stores the source for out-of-tree modules and rebuilds them automatically whenever a new kernel is installed, so drivers like NVIDIA, VirtualBox, and ZFS keep working across kernel updates.

Why do some drivers need DKMS at all?

Because they are not in the mainline kernel, usually for licensing reasons or because the vendor maintains them separately. In-tree drivers ship with the kernel and are always built against it; out-of-tree ones must be compiled against each kernel you install.

What breaks a DKMS build?

Missing kernel headers for the new kernel is the most common cause. After that, a module whose source is too old for the kernel internals it uses, or a full boot partition preventing the resulting initramfs from being written.

How do I check a module built before I reboot?

Run dkms status, which lists every module and the kernels it is installed for. If the new kernel is not listed, the module will not be there after you reboot, which is the moment to fix it rather than after.

Does Secure Boot affect DKMS modules?

Yes. With Secure Boot enabled, unsigned modules are refused, so a module can build successfully and still fail to load. Enrol a machine owner key and sign the modules, or disable Secure Boot.

Can I rebuild DKMS modules manually?

Yes, with dkms autoinstall for all of them or dkms install targeting a specific module and kernel version. This is the recovery step after booting an older kernel when a build failed.