Stop your kernel from autoloading drivers you didn’t ask for

Technical Briefing | 7/25/2026

You probably don’t think about kernel module autoloading until a rogue driver starts causing dmesg spam or hardware conflicts. I once spent an entire afternoon tracking down a thermal throttling issue on a server that turned out to be an accidental wmi_bmof module loading on hardware that didn’t support it. It’s a quiet process, hidden deep in the guts of udev and modprobe, and it usually just works. Until it drags in something that hangs your boot process.

The trap of automatic dependency resolution

When the kernel detects a device or a module alias, it triggers modprobe. Modprobe doesn’t just load the module you asked for; it recursively pulls in every single dependency listed in modules.dep. Most of the time this is a blessing, but if you’re running a hardened production environment or working with specific proprietary hardware, you don’t want the kernel making decisions about what to load. The right approach is to explicitly blacklist modules that you know your infrastructure will never need.

echo 'blacklist firewire_core' > /etc/modprobe.d/blacklist-custom.conf
echo 'install firewire_core /bin/true' >> /etc/modprobe.d/blacklist-custom.conf
depmod -a

• Blacklisting prevents the module from loading automatically via udev triggers.
• Using the install /bin/true trick makes the module impossible to load even if a user explicitly calls modprobe.
• Always run depmod after touching the configuration directory to update the module dependency database.

If you are still seeing the module show up in lsmod after a reboot, something else is force-loading it. Check your initramfs configuration. If the module is baked into the initial ramdisk image, no amount of blacklist configuration in your root filesystem will stop it. You’ll need to update the initramfs using dracut or mkinitcpio to scrub it from the boot process entirely.