Stop depmod from guessing wrong when you backport kernel modules

Technical Briefing | 8/17/2026

You spend all afternoon compiling a custom driver for an old storage controller that the mainline kernel dropped support for years ago. You drop the .ko file into /lib/modules/$(uname -r)/extra, run depmod, and assume you are ready to modprobe. But when the server reboots, the system stays dark because it loaded a generic, buggy module instead of your shiny new build. This happens because depmod prioritizes the modules.dep file based on version metadata and built-in symbol aliases that often clash during backports.

Why depmod gets confused

The kernel module loader is actually pretty simple: it looks at the dependency graph generated by depmod. When you have a custom module that exports the same symbols as a system one, or a module that lacks explicit version magic, depmod sometimes resolves the dependency path to the stock kernel module instead of your custom path. Most engineers ignore the output of depmod, but that file is exactly where the conflict is resolved before the kernel even touches your hardware.

depmod -ae -v | grep -E 'conflicting|override'

• Check /etc/depmod.d/ for stray configuration files that might be pinning older directories
• Verify your module version magic with modinfo to ensure it actually matches your running kernel
• Use modprobe -v to see exactly which file path the kernel is trying to load versus what you expected

If you find yourself chasing your tail, verify the module aliases by inspecting the output of modprobe –show-depends. Sometimes the culprit is a hidden alias in a configuration file under /etc/modprobe.d/ that is forcing an older version of the driver to register first. Cleaning up those legacy aliases usually fixes the issue for good, saving you from a panic-stricken midnight kernel panic during the next maintenance window.