Self-Hosted Linux Kernel Module Management: DKMS vs akmods vs module-assistant (2026)

When you install third-party kernel modules on a self-hosted Linux server — NVIDIA GPU drivers, VirtualBox guest additions, WireGuard out-of-tree modules, or custom hardware drivers — those modules must be rebuilt every time the kernel updates. Without automated module management, a routine apt upgrade or yum update can leave your server unable to load critical drivers until you manually recompile them.

This guide compares the three primary kernel module management frameworks available on Linux: DKMS (Dynamic Kernel Module Support), akmods (Automatic Kernel Module Support), and module-assistant. We cover how each tool handles automatic module rebuilding, configuration patterns, and which solution fits your self-hosted infrastructure best.

What Is Kernel Module Management?

Linux kernel modules are loadable pieces of code that extend kernel functionality without requiring a full system reboot. Out-of-tree modules — those not included in the mainline kernel source — must be compiled against the specific kernel version running on your system. When the kernel updates, the module binary becomes incompatible and must be rebuilt.

A kernel module management framework automates this rebuild process by:

• Detecting when a new kernel is installed
• Rebuilding registered modules against the new kernel headers
• Installing the rebuilt modules into the correct kernel module directory
• Cleaning up old module builds to save disk space

Without such a framework, administrators must manually track kernel updates and recompile modules — a risky proposition for production servers running custom hardware drivers.

DKMS (Dynamic Kernel Module Support)

DKMS is the most widely used kernel module management framework. Originally developed by Dell for Linux workstations, it is now available on virtually all major distributions. DKMS maintains a database of registered modules and automatically rebuilds them when new kernels are installed.

How DKMS Works

DKMS operates through a source tree convention. Module sources are placed in /usr/src/<module-name>-<version>/ with a dkms.conf configuration file that specifies build instructions:

1
2
3
4
5
6
7
8

PACKAGE_NAME="nvidia"
PACKAGE_VERSION="550.54.14"
CLEAN="make clean"
MAKE[0]="make -j$(nproc) module"
BUILT_MODULE_NAME[0]="nvidia"
DEST_MODULE_LOCATION[0]="/updates"
AUTOINSTALL="yes"
REMAKE_INITRD="no"

When a new kernel is installed via the package manager, DKMS hooks into the post-install process and rebuilds all registered modules:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Register a module with DKMS
sudo dkms add -m <module-name> -v <version>

# Build and install manually
sudo dkms build -m <module-name> -v <version>
sudo dkms install -m <module-name> -v <version>

# Check status of all registered modules
dkms status

# Remove a module from DKMS
sudo dkms remove -m <module-name> -v <version> --all

DKMS provides detailed logging at /var/lib/dkms/<module-name>/<version>/build/make.log, making it straightforward to diagnose build failures after kernel updates.

DKMS on Different Distributions

On Debian/Ubuntu, DKMS is provided by the dkms package:

1

sudo apt install dkms linux-headers-$(uname -r)

On RHEL/Fedora, the same package is available:

1

sudo dnf install dkms kernel-devel kernel-headers

DKMS integrates with apt and dnf through trigger scripts that fire during kernel package installation, ensuring modules are rebuilt before the new kernel is activated.

akmods (Automatic Kernel Module Support)

akmods is the Red Hat/CentOS/Rocky Linux alternative to DKMS. Rather than rebuilding modules on each system during kernel installation, akmods uses a different architecture: it builds RPM packages containing pre-compiled kernel modules, which are then distributed through a local repository.

How akmods Works

The akmods approach follows the RPM packaging model:

1
2
3
4
5
6
7
8

# Install akmods and kernel development packages
sudo dnf install akmods kernel-devel kernel-headers

# akmods builds modules as RPMs stored in /root/rpmbuild/
sudo akmods

# Check the akmods log
cat /var/log/akmods

When a new kernel is installed, akmods checks whether a pre-built RPM exists for the current kernel version. If not, it triggers a build using the module’s source RPM (SRPM) and installs the resulting RPM.

The key difference from DKMS is that akmods builds RPM packages, not raw kernel module files. This means:

• Built modules can be deployed to multiple systems with the same kernel
• RPM transaction tracking ensures clean uninstallation
• Modules follow the distribution’s packaging standards

akmods Configuration

akmods sources are placed in /usr/src/akmods/ with a spec file defining the build:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

Name:   kmod-wireguard
Version: 1.0.20240101
Release: 1
Summary: WireGuard kernel module
BuildRequires: kernel-devel >= 5.6

%description
Out-of-tree WireGuard kernel module built via akmods.

%files
/lib/modules/%{kversion}/extra/wireguard.ko.xz

module-assistant

module-assistant is the Debian-specific kernel module build tool. It automates the process of finding, downloading, compiling, and packaging out-of-tree kernel modules as Debian packages.

How module-assistant Works

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Install module-assistant and prepare the system
sudo apt install module-assistant
sudo m-a prepare

# Build and install a module
sudo m-a a-i <module-name>

# Update the module list
sudo m-a update

# Clean old builds
sudo m-a clean

module-assistant maintains a list of known modules with associated source packages. When you request a module build, it:

1. Downloads the source package
2. Compiles it against the current kernel headers
3. Creates a .deb package
4. Installs the package via dpkg

Unlike DKMS, module-assistant does not automatically rebuild modules on kernel updates. It is an on-demand tool, making it suitable for administrators who prefer explicit control over when modules are rebuilt.

Comparison: DKMS vs akmods vs module-assistant

Why Self-Host Kernel Module Management?

For self-hosted infrastructure, kernel module management is a critical operational concern. Whether you are running a home lab with GPU-accelerated media transcoding, a production server with hardware RAID controllers, or a cluster of nodes with custom network interface cards, out-of-tree kernel modules are often essential for hardware functionality.

Data ownership and hardware compatibility. When you control your own servers, you choose the hardware. Many specialized devices — Mellanox NICs with custom RDMA drivers, LSI RAID controllers with proprietary management modules, or FPGA acceleration cards — require out-of-tree kernel modules. A module management framework ensures these drivers survive kernel updates without manual intervention.

Cost savings over vendor-managed solutions. Enterprise server vendors often bundle kernel module management into their support contracts. With open-source tools like DKMS, akmods, or module-assistant, you get the same automation without the licensing overhead. This matters for self-hosted deployments where every server runs dozens of kernel modules.

No vendor lock-in. DKMS works across distributions. If you migrate from Ubuntu to Rocky Linux, your DKMS-registered modules will continue to rebuild automatically. akmods ties you to the RPM ecosystem, and module-assistant to Debian, but DKMS provides distribution-independent module management.

Operational reliability. For servers running 24/7 without reboots, kernel live patching combined with DKMS means security patches can be applied without disrupting module-loaded hardware. Our guide on Linux kernel live patching covers how kpatch, kGraft, and Canonical Livepatch work alongside module management frameworks.

For related reading, see our Linux crash dump analysis guide for troubleshooting module-related kernel panics, and our Linux LVM management guide for storage-level module management.

Best Practices for Production Servers

1. Always install matching kernel headers — DKMS and akmods require the exact kernel headers for the running kernel. Install linux-headers-$(uname -r) (Debian) or kernel-devel (RHEL) before registering modules.

2. Pin module versions — When a module works reliably, pin its version in the DKMS database to prevent accidental upgrades:

   1 2	sudo dkms remove -m <module> -v <version> --all sudo dkms add -m <module> -v <version>

3. Clean old builds regularly — DKMS accumulates build artifacts. Remove old module versions:

   1	sudo dkms remove -m <module> -v <old-version> --all

4. Monitor DKMS logs after kernel updates — Check /var/lib/dkms/*/build/make.log for compilation errors. Failed builds mean the module will not load after reboot.

5. Test module rebuilds in staging — Before deploying a kernel update to production, verify that all DKMS modules rebuild successfully on a staging server with the same configuration.

FAQ

What happens if DKMS fails to rebuild a module after a kernel update?

If DKMS compilation fails, the old module remains in the previous kernel’s directory. The new kernel will boot without the module loaded. Check the build log at /var/lib/dkms/<module>/<version>/build/make.log for the specific error. Common causes include missing kernel headers, incompatible module source code, or compiler version mismatches. Fix the issue, then manually run sudo dkms install -m <module> -v <version> to rebuild.

Can I use DKMS on RHEL/CentOS systems?

Yes, DKMS is available in the EPEL repository for RHEL and CentOS: sudo dnf install epel-release && sudo dnf install dkms. However, on RHEL-family systems, akmods is the native tool and is generally preferred because it integrates with the RPM package management system and produces distributable RPM packages.

Does module-assistant automatically rebuild modules on kernel updates?

No. module-assistant is a manual, on-demand tool. It does not hook into the kernel package installation process. If you need automatic rebuilding on Debian systems, DKMS is the better choice. module-assistant is best for one-off module builds or environments where administrators prefer explicit control over rebuild timing.

How much disk space does DKMS consume?

Each DKMS build creates a source tree in /usr/src/ and build artifacts in /var/lib/dkms/. A single module build typically uses 50–200 MB depending on the module size. For servers with many out-of-tree modules, run du -sh /var/lib/dkms/ to check usage and remove old versions with dkms remove.

Can I use multiple module management frameworks on the same system?

Technically yes, but it is not recommended. DKMS and akmods can coexist on RHEL systems, but they may conflict over which framework rebuilds a given module. Choose one framework and register all modules through it. On Debian, DKMS and module-assistant can coexist because module-assistant is manual-only and does not conflict with DKMS hooks.

Is DKMS required for in-tree kernel modules?

No. In-tree modules (those shipped with the mainline kernel source) are compiled as part of the kernel build and installed with the kernel package. DKMS only manages out-of-tree modules — third-party drivers that are not part of the mainline kernel source.