Stop the kernel from auto-loading modules you never asked for

Technical Briefing | 11/12/2026

You spend days tuning your stack, pinning down every variable in your kernel config, only to run a probe command and watch the kernel happily pull in a half-dozen modules you explicitly disabled or didn’t even know existed. It happens because udev is doing its job too well, watching hardware events and mapping them to modules based on aliases. If you’ve ever dealt with mysterious driver conflicts or security audits, you know that letting the kernel auto-load everything it thinks it needs is a liability.

Why modprobe thinks it knows better than you

The kernel uses the module alias mechanism to facilitate hardware detection, but these aliases are often broad. When udev triggers a match, it invokes modprobe, which scans /lib/modules/$(uname -r)/modules.alias. This file is a massive map linking hardware IDs to driver files. Most sysadmins ignore it, but when you need to blacklist a specific piece of hardware functionality to prevent a sensitive peripheral from exposing its interface, the blacklist file in modprobe.d is your only defense against this auto-loading behavior.

echo 'install pcmcia_core /bin/true' > /etc/modprobe.d/disable-modules.conf

• Using install /bin/true prevents the module from loading by forcing it to return a successful status immediately
• Blacklisting a module only blocks automatic loading, not manual modprobe commands
• Always verify your changes with lsmod after triggering a hardware probe

If you are struggling with a driver that keeps coming back, stop relying on the standard blacklist files. The install trick effectively neuters the module at the binary level. Next time you see an unnecessary kernel module creeping into your runtime environment, you know exactly where to intercept it.