You Told The Kernel To Stop Loading That Module. It Didn’t Listen.

Technical Briefing | 10/16/2026

We’ve all been there: you’ve got a hardware component or a driver that’s causing grief. Maybe it’s an old `nouveau` driver fighting with your shiny new NVIDIA blob, or a dodgy `r8169` network driver acting up on certain hardware, making you wish for `r8168`. So you blacklist it. You edit `/etc/modprobe.d/blacklist.conf`, add `blacklist foo`, run `depmod -a`, and reboot. Feeling accomplished, you `lsmod` only to see `foo` right there, loaded and laughing at you. What gives? It’s a common trap, and frankly, `blacklist` isn’t always enough.

Blacklisting Isn’t Always the Final Word

The `blacklist` directive in `modprobe.d` tells the kernel ‘don’t load this module *directly*.’ And that’s usually fine. But kernels are clever, sometimes too clever for our own good. If another module you *do* need lists your troublesome `foo` as a dependency, the kernel’s module loader will happily pull `foo` in anyway. You could spend ages tracing `modinfo` output to build a complex chain of blacklists, but there’s a more direct way to tell the kernel, ‘No, seriously, never load this module, period.’ It’s the `install` command, and it gives you a lot more control than `blacklist` ever will.

install nouveau /bin/true
options nouveau modeset=0


sudo depmod -a
sudo update-initramfs -u

The Initramfs: Early Boot’s Silent Assailant

The code above does two critical things. First, `install nouveau /bin/true` is a sledgehammer: it tells `modprobe` that whenever `nouveau` is requested, it should instead run `/bin/true`, which just exits successfully without loading anything. That’s a powerful override. Second, `options nouveau modeset=0` isn’t strictly necessary for a total block, but it’s a good habit to disable any module options if you’re trying to prevent it from initializing properly, just in case. But here’s the kicker: if the module is embedded in your initial ramdisk (`initramfs`), it’ll load before `modprobe` or your custom `modprobe.d` rules even get evaluated. That’s why running `update-initramfs -u` is absolutely vital. It rebuilds the ramdisk, ensuring your module is actually removed from the early boot environment. Otherwise, you’re back to square one, wondering why your carefully crafted rules aren’t sticking.

• Check `lsmod` *after* a full reboot to see if it’s still there. `modprobe -r` only unloads, doesn’t prevent future loads.
• Use `modinfo <module_name>` to understand its dependencies and any `alias` names that might pull it in.
• Scan `/etc/modprobe.d/` for conflicting rules with `grep -r <module_name> /etc/modprobe.d/`.
• Verify the `install` directive is present and correct, and that you ran `depmod -a`.
• Confirm you rebuilt the initramfs with `update-initramfs -u` or the equivalent for your distro (like `dracut -f` on Fedora/RHEL).

Module management isn’t just about loading what you need; it’s just as much about preventing what you *don’t*. Understanding how `modprobe` works under the hood, especially its `install` directive and the role of the initramfs, gives you complete control. It’s a small detail, but when a problematic module is crashing your system or causing weird hardware behavior, knowing these tricks saves you hours of head-scratching. Don’t just blacklist; actively disable.