I'm curious about why kernel modules need to be updated or preserved during system updates in Linux distributions. How do these modules interact with updates, and what impact can they have on system stability and security? What approaches are preferred to prevent module compatibility issues? How do you handle this situation yourself?
What is the role of kernel modules during system updates in Linux?
👁️ 74 views💬 3 replies❤️ 0 likes
3 Replies
The last time I updated Ubuntu Server in a production environment, the kernel was upgraded to a newer 5.15 version, while a few proprietary drivers (notably for the RAID controller) remained as external modules. After reboot, the system failed to load these modules—they required symbols from the old kernel, and `modprobe` complained about version mismatches. To avoid downtime, I had pre-built the module for the new kernel using `dkms`, placing the configuration in `/etc/dkms/`. When the update went through, `dkms` automatically rebuilt the driver and installed it under `/lib/modules/5.15.0/...`. This approach "protected" the module from incompatibility, keeping the system stable and secure.
In practice, I also use `apt-mark hold` for critical kernel packages if there’s a risk that a new module might break specific hardware. After testing in an isolated VM, I lift the hold and allow the system to update. This "test-in-container → build-via-dkms → production-deployment" cycle helps minimize module compatibility issues and keeps operations running without unexpected failures.
A module is typically a separate object file that's only loaded into the kernel when needed. When updating the kernel, distributions usually install two sets of modules: one for the current kernel version and another for the new one. This is done to ensure the system can still boot even if the new set of modules isn't yet compatible with user space or proprietary drivers. Package managers (rpm, apt, pacman) typically mark old .ko files as "obsolete" and only remove them after a successful reboot, giving you a chance to roll back if needed.
From a security standpoint, updated modules often include fixes for vulnerabilities in drivers (e.g., network or file system subsystems). If you keep an old module, a potential exploit could remain active even after the kernel has been patched. That's why in production environments, it's recommended to reboot immediately and ensure only the new modules are loaded. However, in some cases (especially on long-running servers), admins use tools like **kmod-reload** or **kpatch** to replace only the necessary modules without a full reboot.
What strategies do you usually use to avoid conflicts between the kernel and external drivers? Do you pin module versions in a separate repository, or do you rely on automatic package rollbacks? And how often do you check the integrity of loaded modules after an update?
Thanks for the great question! When updating the kernel, I usually use `dkms` to automatically rebuild modules and keep them compatible. Do you prefer keeping modules in `/usr/lib/modules` or compiling them manually?