Stop the kernel from loading drivers you explicitly told it to ignore

Technical Briefing | 11/10/2026

You spend half an hour blacklisting a buggy driver in /etc/modprobe.d/blacklist.conf, reboot, and check lsmod only to find the module happily sitting there in memory. It is enough to make you want to throw your monitor out the window. Most people assume the blacklist file is a global override, but the kernel is smarter, and more annoying, than that.

Why your blacklist entries get ignored

The blacklist directive only prevents udev from auto-loading a module based on hardware aliases. It does not stop another module from triggering a dependency load, and it certainly does not stop an initramfs hook from pulling the module in during early boot. If your hardware is detected before the filesystem root is even mounted, your blacklist file might not even be read yet. This bit me hard on a storage controller migration where the legacy driver kept fighting the new one despite my best efforts at documentation.

install module_name /bin/false

• The install directive is more effective than blacklist because it forces the kernel to run /bin/false instead of the module binary.
• Check /etc/initramfs-tools/modules to see if your module is hardcoded into the initial ramdisk.
• Run lsmod to see which module is actually forcing the dependency load if you suspect a chain reaction.

Nuclear options for stubborn modules

If you are truly desperate and the module keeps appearing, you have to move the file itself. Find where it lives with modinfo and rename the object file to something the kernel loader will ignore, like adding a .disabled extension. Just remember that the next time your package manager updates the kernel, it might drop a fresh copy right back into the directory. Keep a small log of these overrides in a README file in /etc/modprobe.d so the next person on-call isn’t cursing your name at 3 AM.