Kernel module dependency not found after kernel update fix

You just ran yum update or apt upgrade on a RHEL 8, CentOS 7, or Ubuntu 22.04 box. Rebooted. Now modprobe bonding or modprobe nfs gives you FATAL: Module not found. But the module file is sitting right there in /lib/modules/$(uname -r)/. This is a classic dependency resolution failure after a kernel update.

What's really happening here

The culprit is almost always a stale modules.dep file. When you install a new kernel via a package manager, it normally runs depmod automatically. But sometimes it doesn't. Common triggers:

• You manually installed a kernel from a .rpm or .deb without triggering the post-install scripts
• You're using a custom kernel compiled from source and forgot to run depmod
• The update script failed silently because of disk space or permissions
• You're on a minimal install like Docker container that skips depmod

The kernel only checks the dependency map. If the map doesn't list the module, it won't load even if the .ko file exists. Simple as that.

The fix: rebuild the dependency map

Don't bother reinstalling the kernel or rebooting again. That rarely helps. Here's what works:

1. Find your current kernel version
   Run uname -r. Write it down. Example output: 5.14.0-284.11.1.el9_2.x86_64
2. Locate the module directory
   Check ls /lib/modules/$(uname -r)/. If you see modules.dep but it's tiny (like 1KB), it's stale. A healthy one is hundreds of KB to a few MB.
3. Backup the old map (optional but safe)
   cp /lib/modules/$(uname -r)/modules.dep /lib/modules/$(uname -r)/modules.dep.bak
4. Run depmod to rebuild
   depmod -a works for the current kernel. If you're fixing a different kernel version, specify it: depmod -a 5.14.0-284.11.1.el9_2.x86_64
5. Verify the fix
   Check the file size again: ls -lh /lib/modules/$(uname -r)/modules.dep. Should be much larger now. Then try loading your module: modprobe bonding (or whatever failed).

If it still fails

Here are the things I check next, in order:

• Is the module actually in the tree?
  find /lib/modules/$(uname -r) -name '*.ko' | grep -i bonding. If it's missing, your kernel doesn't have it compiled. You need to install the matching kernel-modules-extra package.
• Are there conflicting modules?
  Sometimes a module is blacklisted. Check /etc/modprobe.d/. If you see a blacklist.conf file, comment out the blacklist line.
• Did you try the full rebuild?
  depmod -a -v $(uname -r) shows verbose output. Look for errors like "cannot find .ko" or permission denied.
• Is your kernel version mismatched?
  After a partial update, you might be booting an old kernel. rpm -qa kernel or dpkg -l linux-image-* shows installed kernels. Reboot into the correct one if needed.
• Last resort: force module load
  insmod /path/to/module.ko bypasses dependency resolution. Use this only for troubleshooting. It won't load dependencies automatically.

I've seen this exact issue at least 50 times in production. 90% of the time it's just running depmod. The other 10% is a missing kernel module package. Don't overthink it.