You added `blacklist nouveau` to a file under /etc/modprobe.d on a Linux server, yet after a reboot the module is loaded again. Why can a blacklist entry fail to take effect, and how do you actually keep the module out?
answer
- it suppresses aliases, not the name
- dependencies still pull it in
- early boot has its own copy of /etc
- replace the load action, not just deny it
- a boot parameter covers the whole boot
basics
~20 sA blacklist line only suppresses loading through the module's aliases, so on-demand hardware autoload is blocked but an explicit modprobe, a pull-in as another module's dependency, or a stale copy of the config inside the initramfs still loads it. The reliable stop is an install line pointing at /bin/false plus a regenerated initramfs.
solid answer
~50 s`blacklist <name>` is narrower than most people assume: it tells `modprobe` to ignore that module when it is requested *by an alias*, which is how hardware discovery asks for a driver. It does not block `modprobe nouveau` typed explicitly, and it does not block the module being pulled in because some other module depends on it. Three more reasons the entry can look ignored: the module was loaded from the initramfs before the root filesystem existed, so the initramfs's own copy of `/etc/modprobe.d` applied and must be regenerated; something is calling `insmod`, which does not read that directory at all; or the driver was compiled into the kernel, in which case there is no load event to suppress. The blunt instrument is `install nouveau /bin/false` in the same directory, which replaces the load action with a command that fails. For the earliest boot stages, `modprobe.blacklist=nouveau` on the kernel command line covers the window before your configuration is read.
go deeper
Know that blacklisting lives in a .conf file under /etc/modprobe.d and that the change often needs the initramfs regenerated before a reboot reflects it. Confirm afterwards with lsmod rather than assuming.
Explain that blacklist suppresses alias-driven autoload only, so explicit loads and dependency pull-ins still get through, and that the install directive is what replaces the load action outright.
Enumerate every path by which a module can end up loaded — alias autoload, explicit request, dependency, initramfs, raw insert, compiled in — say which of them a blacklist covers, and know the kernel command-line blacklist as both belt-and-braces and recovery.
Treat driver suppression as fleet configuration with a rollback story: the change spans a config file and a regenerated initramfs, it fails silently, and a host that boots without its storage or network driver is unreachable — so it needs staged rollout and a documented boot-parameter recovery.
## What blacklist actually means The `blacklist` keyword in a `/etc/modprobe.d/*.conf` file instructs `modprobe` to ignore all of a module's internal *aliases*. That is precisely — and only — the path used when something asks the system for a driver indirectly: the kernel discovers a PCI device, produces a `modalias` string describing it, and the device manager asks `modprobe` to load whatever claims that string. With the module blacklisted, that request finds nothing. What it does not do is make the module unloadable by name. `modprobe nouveau` still works, by design — blacklisting is a policy about automatic loading, not a lock. ## The five reasons it appears not to work **1. Something requested it by name.** A script, a unit, a vendor installer, or a `modules-load` configuration file that lists the module explicitly will load it regardless of the blacklist. **2. It came in as a dependency.** If another module declares it as a dependency, `modprobe` loads the whole chain. The blacklist covers alias resolution, not dependency resolution. **3. The initramfs has a stale copy.** This is the classic one for graphics and storage drivers. The initramfs is a self-contained root filesystem containing its own modules and its own copy of the modprobe configuration, and it runs before `/etc/modprobe.d` on the real root is reachable. Editing the file on disk and rebooting changes nothing until you regenerate the initramfs with the distribution's tool (`update-initramfs` on Debian and Ubuntu, `dracut` on RHEL, SUSE and Fedora). **4. Something is using insmod.** `insmod` performs a raw insert and never reads `/etc/modprobe.d`. Any tooling built on it bypasses the entire configuration layer. **5. It is not a module.** If the driver was compiled into the kernel there is no load to suppress. Check whether the name is in `lsmod` at all, and whether it appears in the kernel's built-in list; a built-in driver is disabled with a driver-specific kernel command-line switch or not at all. ## The mechanisms that actually keep it out **The install override.** `modprobe` supports an `install <module> <command>` directive that replaces the normal insert with an arbitrary command. Point it at something that fails: ``` # /etc/modprobe.d/disable-nouveau.conf blacklist nouveau install nouveau /bin/false ``` Now every `modprobe` route — by name, by alias, as a dependency — runs `/bin/false` instead of inserting the module. Keep the `blacklist` line too: the two cover different paths, and the pair is the recipe every vendor driver installer ships. Note that this still does not stop a direct `insmod`, which is fine, because a direct `insmod` is a deliberate act. **Regenerate the initramfs.** Whatever you write, run the distribution's initramfs tool afterwards if the module can load before the root filesystem is mounted. Skipping this is the single most common cause of "I blacklisted it and it is still loaded". **The kernel command line.** `modprobe.blacklist=nouveau` passed as a boot parameter blacklists the module for the whole boot, including the initramfs stage, without touching any file. It is both a belt-and-braces addition for the earliest stages and the recovery route when a machine has become unbootable — you can also use it interactively from the boot loader for a single boot. ## Verifying rather than hoping After the change, reboot and confirm with `lsmod` that the module is absent, and check the kernel log for a driver that bound the hardware instead. If the module is still there, work the list above in order: was it requested by name, is it someone's dependency (check the holders in sysfs), was the initramfs regenerated, is it even a module. ## Why this is a senior question It is a small, concrete situation that punishes a shallow model. The candidate who thinks blacklist means "forbidden" has no next step when it does not work. The candidate with the model can enumerate the load paths — alias, explicit name, dependency, initramfs, insmod, built-in — and say which of them a blacklist covers and which it does not. That enumeration *is* the answer, and it generalises to every "my configuration was ignored" problem in the module subsystem.
- Why keep the blacklist line at all if the install override already stops every modprobe path?Because they are documented as different behaviours and both are cheap. The blacklist entry expresses the intent to suppress alias-driven autoload, which is what tooling and other administrators read; the install override is the enforcement. Every vendor driver installer ships the pair, and dropping one is the kind of thing that quietly stops working after a distribution changes its defaults.
- How would you disable a driver that turns out to be compiled into the kernel rather than built as a module?Nothing in /etc/modprobe.d can help — there is no load event. You are limited to whatever the driver itself accepts on the kernel command line, a generic mechanism such as unbinding the device from the driver at runtime if the subsystem supports it, or running a different kernel build. Establishing which case you are in, by checking lsmod and the built-in list, should be step one.
- A colleague blacklists a module and reboots without regenerating the initramfs. What happens and why?The module loads anyway during early boot. The initramfs is a separate root filesystem with its own copy of the modules and the modprobe configuration, assembled when it was last generated, and it runs before the real root is mounted. Once the driver has bound the hardware there, nothing later unloads it. Regenerating the initramfs is what propagates the change.
saying these in an interview costs you the question
- Believes blacklist forbids all loading of the module
- Forgets the initramfs carries its own modprobe config
- Thinks a blacklist stops a dependency pull-in
- Never checks whether the driver is built into the kernel
- Assumes insmod respects /etc/modprobe.d