Stop fighting module load order when dkms fails you

Technical Briefing | 10/1/2026

You probably rely on dkms to keep your custom kernel modules alive across updates. Most of the time it works, but I have seen it silently fail to rebuild a critical driver because the kernel headers were mismatched or the build environment had stale artifacts. When that happens, your server boots into a generic kernel, your network interfaces vanish, and you are left staring at a serial console wondering why your module failed to load.

The module dependency trap

When you have a custom kernel module that relies on another module being loaded first, putting them in /etc/modules is lazy and often ineffective. Systemd is going to parallelize the load process anyway. If your hardware driver initializes before the low-level bus driver it requires, you end up with a kernel taint or a dead interface. You need to use modprobe.d configuration files to handle these dependencies correctly so the kernel knows the correct sequence, regardless of how fast systemd thinks it can start things up.

echo 'softdep bus_driver pre: core_driver' > /etc/modprobe.d/driver-order.conf

• The softdep directive tells modprobe to ensure the dependency is loaded without forcing a hard error if it is missing
• Always verify your load order with lsmod immediately after boot to confirm the hierarchy you expect
• Check /var/log/dmesg for hidden module parameter errors that never make it to your syslog

Why relying on automatic modprobe is risky

I have seen developers try to fix module issues by appending to /etc/rc.local, which is a complete disaster. It creates a race condition where udev might try to re-trigger the module load at the exact same time your script fires. If you have an exotic module that requires specific parameters to actually work, put those into a dedicated file in /etc/modprobe.d/ instead of trying to script it after the fact. It keeps your kernel log clean and prevents those annoying midnight alerts when the module fails to initialize on a reboot.

Next time a module fails to stick, stop rebooting in hopes it fixes itself. Check your softdep configuration first, and you will likely find a missing link in the chain that udev was never told about.