When a driver keeps grabbing hardware you want to ignore
You just installed a new Wi-Fi card or switched to a proprietary graphics stack. The system boots, but the old open-source driver keeps claiming the device. You try removing the package, but the kernel still loads the conflicting module on every restart. The hardware stays locked up, or the system falls back to a slow generic driver. You need a reliable way to tell the kernel to ignore that specific module permanently.
What the kernel actually does with modules
The Linux kernel does not compile every available driver into the main boot image. It uses a modular design. Core functionality lives in the vmlinuz file. Everything else sits in separate .ko files under /lib/modules/$(uname -r)/kernel/. When hardware appears, the kernel checks its module dependency tree and loads what it thinks matches. Sometimes that guess is wrong. Sometimes a legacy driver claims a device that a newer driver should handle. Sometimes a buggy module causes a panic. Blacklisting tells the module loader to skip that file entirely, even if the hardware matches its ID table.
Think of the kernel module loader like a restaurant kitchen. The menu lists every dish the kitchen can prepare. When a customer orders, the chef grabs the recipe. Blacklisting is like taking that recipe off the shelf and locking it in a drawer. The kitchen still knows the dish exists, but it will never prepare it unless you manually hand the chef the recipe.
Fedora follows the standard Linux convention for module configuration. User modifications belong in /etc/modprobe.d/. Package-managed defaults live in /usr/lib/modprobe.d/. Never edit files in /usr/lib/. Package updates will overwrite them. Always create new files in /etc/ to override the defaults.
Run journalctl first. Read the actual error before guessing.
How to blacklist a module properly
Identify the exact module name before writing any configuration. Run lsmod to see what is currently loaded. The first column shows the module name without the .ko extension. Note the exact spelling. Kernel module names are case-sensitive and often use underscores instead of hyphens.
Create a configuration file in the modprobe directory. The filename should clearly indicate which module you are blocking. This keeps your configuration readable when you have multiple overrides.
# Create a dedicated config file for the module you want to block
# Replace nouveau with your actual module name
# tee writes to the file as root and discards stdout to keep the terminal clean
sudo tee /etc/modprobe.d/blacklist-nouveau.conf > /dev/null <<EOF
blacklist nouveau
options nouveau modeset=0
EOF
The blacklist directive tells modprobe to ignore the module during automatic loading. The options line is optional but often necessary. Some modules will still load if another driver depends on them. Adding options <module> modeset=0 or similar parameters can prevent fallback behavior. Check the module documentation if the blacklist alone does not stop it from loading.
After writing the configuration, you must rebuild the initial ramdisk. The initramfs contains a snapshot of the modules and configuration needed to mount the root filesystem. If the blacklist is not baked into the initramfs, the kernel will load the module before your /etc/ configuration takes effect.
# Rebuild the initramfs for the currently running kernel
# This ensures the blacklist is active from the earliest boot stage
# --force skips the version check and rebuilds unconditionally
sudo dracut --force
The dracut command reads /etc/modprobe.d/ and generates a new compressed image. It replaces the old one in /boot/. The package manager handles kernel updates automatically, but manual config changes require an explicit rebuild. Fedora also runs depmod during the dracut process. depmod scans /lib/modules/ and rebuilds the modules.dep cache. That cache tells the kernel which modules depend on which others. If you skip dracut, the dependency cache stays stale and the old module still loads.
Reboot the system. The module will no longer load automatically.
Snapshot the system before the upgrade. Future-you will thank you.
Verify the blacklist took effect
Confirm the blacklist worked before moving on to other troubleshooting steps.
# Check if the module is currently loaded
# An empty output means the blacklist is working
lsmod | grep nouveau
If the module still appears, check the journal for dependency chains. Another module might be pulling it in.
# Search the boot log for the module name
# Look for lines indicating automatic loading or dependency resolution
journalctl -k | grep -i nouveau
You will see messages like module loaded or loaded by dependency. If a dependency is pulling it in, you need to blacklist the parent module as well. The kernel module loader follows the dependency tree strictly. Blocking one leaf node does not stop the root from loading.
Run modinfo <module-name> to inspect the alias table. The alias lines show which hardware IDs trigger the load. If you see alias pci:v000010DEd00001381sv*sd*bc*sc*i*, the module claims NVIDIA hardware. Blacklisting it prevents that claim.
# Inspect the hardware IDs and dependencies for the module
# The depends line shows what pulls this module in
modinfo nouveau | grep -E "alias|depends"
If the depends line lists another module, blacklist that one too. The kernel will not load a module if any of its required dependencies are blacklisted.
Trust the package manager. Manual file edits drift, snapshots stay.
Common pitfalls and what the error looks like
Blacklisting is not a magic switch. Several common mistakes break the process.
The most frequent error is editing the wrong directory. Users often modify /usr/lib/modprobe.d/dist-blacklist.conf. That file belongs to the kernel-modules package. The next dnf upgrade will overwrite your changes. Always create new files in /etc/modprobe.d/.
Another pitfall is forgetting the initramfs rebuild. You can blacklist a module in /etc/ and reboot, only to find it still loaded. The kernel boots from the initramfs first. The root filesystem mounts later. If the blacklist is not in the initramfs, the early boot stage loads the module anyway. Run sudo dracut --force after every change to /etc/modprobe.d/.
Some users try to remove the .ko file directly from /lib/modules/. This breaks depmod and can corrupt the module dependency cache. The package manager will also restore the file on the next kernel update. Blacklisting is the supported path.
If you see modprobe: FATAL: Module nouveau not found in module directory, you typed the name wrong. Kernel modules do not use hyphens in their internal names. nvidia-drm is nvidia_drm in the kernel. Check lsmod or /lib/modules/$(uname -r)/kernel/drivers/ for the exact spelling.
SELinux does not block module loading. You will not see AVC denials for blacklisted modules. The module loader runs in kernel space. SELinux policies apply to userspace daemons. Do not disable SELinux to fix a module loading issue.
Firmware blobs are different from kernel modules. Blacklisting iwlwifi does not stop the firmware from loading. Firmware lives in /lib/firmware/ and is loaded by the driver itself. If you need to block firmware, you must blacklist the driver that requests it.
Run journalctl first. Read the actual error before guessing.
When to blacklist versus other approaches
Use blacklisting when you want to permanently prevent a specific driver from loading automatically. Use modprobe -r when you need to unload a module temporarily for testing. Use systemctl mask when you want to stop a userspace service that triggers module loading. Use dnf remove when the module belongs to a package you no longer need. Use kernel parameters like module_blacklist= on the GRUB command line when you need a one-time override for debugging. Stay on the blacklist approach for hardware conflicts and driver fallback issues.
Reboot before you debug. Half the time the symptom is gone.