When modprobe fails because of hidden symbol dependencies

Technical Briefing | 7/12/2026

You probably think the kernel module dependency chain is handled entirely by modules.dep. Most of the time you are right, until you aren’t. I spent a whole morning once wondering why a proprietary driver would load in a clean VM but fail on production hardware with a generic Unresolved symbol error that did not appear in any log files.

The kernel keyring is not just for signing

It is easy to assume that modprobe just reaches into /lib/modules and does its thing. But if you have forced module signature verification on, you are not just checking headers. You are trusting the kernel keyring. If your module depends on a symbol exported by another module that is not yet signed or loaded, the linker in the kernel just gives up. This bit me when a staging driver relied on a specific sub-module for crypto support that was excluded from the initial ramdisk build.

modprobe --verbose --dry-run my_problematic_module

• Check /proc/modules to see if a phantom sub-module is partially initialized
• Verify the symbol exports by inspecting the module binary directly with modinfo
• Look for missing kernel features that provide the requested symbol in the first place

The fix is usually to verify that your initramfs actually includes the base modules your driver needs. If you are using Dracut, check the add_drivers directive in your config. Sometimes the automated dependency resolver just misses the edge cases where a symbol is only provided by a specific sub-driver. If you ever see mysterious failures that vanish after a manual insmod of the base module, stop trusting the automated load process and start pinning your dependencies manually in /etc/modules-load.d.