You spend all morning configuring a custom network stack or debugging an obscure hardware passthrough issue, only for the kernel to unilaterally decide that it knows better. You blacklist a module, it seems to work, and then a reboot happens or a hot-plug event triggers, and the wrong driver claims your interface again. It’s frustrating when udev ignores your local preferences just because it found a compatible PCI ID.

The myth of the simple blacklist

Most people assume that dropping a file in /etc/modprobe.d/ is the end of the story. But blacklist only prevents the kernel from auto-loading a module when it scans for hardware. It doesn’t actually stop other modules or userspace tools from explicitly requesting the driver. I have seen systems where a random dependency chain drags the forbidden driver back into memory anyway. You need a hammer, not a suggestion.

echo install modulename /bin/true | sudo tee /etc/modprobe.d/force-disable.conf

• Using the install command with /bin/true renders the loading process a no-op.
• The kernel will think it successfully loaded the module while doing absolutely nothing.
• This approach survives most dependency resolution attempts that plain blacklisting fails to stop.

When to actually use this trick

Only pull this out if you are dealing with conflicting drivers, like trying to force a non-standard kernel driver over the generic in-tree one. Don’t go overboard here, or you’ll be the one debugging a boot loop six months from now when you forget why your NIC stopped working. If you’re going to break the automatic behavior, document it in the file name itself so your future self doesn’t curse your past choices.