Kernel modules — load, list, dependencies, blacklist · Linux

The Linux kernel is modular. Most drivers and filesystems are loadable kernel modules (LKMs) that the kernel loads on demand. Managing modules — listing, loading, unloading, blacklisting — is a core sysadmin skill.

Listing modules

Read-only / Safelsmod— lsmod lists every loaded module with its size and 'used by' count. dm_multipath depends on dm_mod (note 'used by' shows dm_mod is used 9 times). Modules loaded as dependencies are listed separately from the modules that triggered their load.

$ lsmod | head

Module                  Size  Used by
nls_iso8859_1           12288  1
dm_multipath           32768  0
dm_mod                131072  9 dm_multipath
...

Illustrative output

Read-only / Safe/proc/modules— /proc/modules is the source data for lsmod. The format is name, size, use count, dependencies, state (Live/Loading/Unloading), and address. The address column is a marker that has been used historically to identify which kernel instance loaded the module (no longer meaningful on systems without module versioning).

$ cat /proc/modules | head

nls_iso8859_1 12288 1 - Live 0x0000000000000000
dm_multipath 32768 0 - Live 0x0000000000000000
...

Illustrative output

Module dependencies

Read-only / Safemodinfo— modinfo shows metadata for a module: filename (in /lib/modules/<kernel-version>/), license, description, dependencies, vermagic (kernel version the module was built for). The vermagic must match the running kernel — a mismatch prevents the module from loading.

$ modinfo dm_multipath

filename:       /lib/modules/6.6.31-linuxkit/kernel/drivers/md/dm-multipath.ko
version:        1.14.0
license:        GPL
description:    device-mapper multipath
author:         ...
depends:        dm-mod
retpoline:      Y
vermagic:       6.6.31-linuxkit SMP preempt mod_unload aarch64

Illustrative output

Loading and unloading

Service impact possiblemodprobe— modprobe MODULE loads a module and everything it depends on. modprobe -r goes the other way, and note the direction carefully: man 8 modprobe says that on removal, if the modules it DEPENDS ON are also unused, modprobe will try to remove them too. It does not remove modules that depend on it - those hold a reference and block the removal with 'Module is in use by ...'. -r --force bypasses the safety check and can panic the kernel. Load and unload are non-destructive for unused modules and disruptive for in-use ones.

$ sudo modprobe br_netfilter; sudo modprobe -r br_netfilter; sudo modprobe -r --force br_netfilter 2>&1

Illustrative output

modprobe.d — module configuration

Read-only / Safemodprobe.d— Files in /etc/modprobe.d/ configure module loading: aliases, options, blacklists. Each file is read at boot and applied. Distribution packages drop their own files; admins can add /etc/modprobe.d/<name>.conf for local overrides. Note what modprobe.d does NOT do: it never causes a module to load. It only shapes what happens when something else asks for one.

$ ls /etc/modprobe.d/

aliases.conf
blacklist.conf
dccp.conf
firewalld-sysctls.conf
...

Illustrative output

Loading a module at every boot

modprobe at the shell is runtime-only. The module is loaded until the next reboot and then it is gone. Nothing in /etc/modprobe.d/ brings it back — that directory configures loads, it does not request them.

The persistent equivalent is /etc/modules-load.d/. At sysinit, systemd-modules-load.service reads every .conf file in it and modprobes each module named, one per line:

Configuration changemodules-load.d— One module per line; blank lines and lines starting with # are ignored. Restarting the unit applies the file immediately, so you test the config now instead of discovering at the next reboot that you typo'd a module name. A failed load is reported by the unit and logged, which is exactly why you check systemctl status rather than assuming success. Search order is /etc/modules-load.d, then /run, then /usr/lib — /etc wins, so a local file overrides a vendor one of the same name.

$ printf 'br_netfilter\nnf_conntrack\n' | sudo tee /etc/modules-load.d/50-network.conf; sudo systemctl restart systemd-modules-load.service; systemctl status systemd-modules-load.service --no-pager; lsmod | grep br_netfilter

br_netfilter
nf_conntrack
● systemd-modules-load.service - Load Kernel Modules
     Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
     Active: active (exited) since Sun 2026-08-09 11:02:14 UTC
br_netfilter           32768  0
bridge                307200  1 br_netfilter

Illustrative output

A sysctl whose module is not loaded is silently not applied

This is the classic container-host failure. An operator enables bridge filtering with modprobe br_netfilter and writes net.bridge.bridge-nf-call-iptables=1 into /etc/sysctl.d/. Everything works. The setting is persisted, so it looks finished.

At the next reboot systemd-sysctl runs before anything has loaded br_netfilter. The net.bridge.* keys do not exist yet, because those sysctls are created by the module. The write fails, systemd logs one line about an unknown key, and the host comes up healthy in every other respect — with container network policy no longer enforced.

The fix is to make the module load persistent too. Anything you persist in /etc/sysctl.d/ that belongs to a module needs a matching entry in /etc/modules-load.d/. The sysctl file is only half the change.

Blacklisting

Read-only / Safeblacklist— blacklist <module> in a modprobe.d file suppresses ALIAS-based auto-loading of that module — the path the kernel uses when hardware is detected or a subsystem requests a driver by alias. It does not remove an already-loaded module, and it does not stop an explicit modprobe or a load pulled in as another module's dependency.

$ cat /etc/modprobe.d/blacklist-floppy.conf

# Some chassis hardcode the floppy driver into the BIOS,
# and it can interfere with detection of the SATA drive.
blacklist floppy

Illustrative output

blacklist is not a disable switch

man 5 modprobe.d is precise about the limit: the blacklist keyword applies only to alias-based autoloading. Three loads still succeed against a blacklisted module:

An explicit modprobe usb-storage by a user or a script.
A load triggered as another module’s dependency.
A load from the initramfs, before /etc/modprobe.d/ is read.

To close every path, pair the blacklist with an install line that replaces the module’s load command with a program that does nothing and fails:

# /etc/modprobe.d/99-disable-usb-storage.conf
# blacklist stops the ALIAS path; install stops every path
blacklist usb-storage
install usb-storage /bin/false

install tells modprobe to run the given command instead of inserting the module. /bin/false runs, exits non-zero, and the module is never inserted — whether the request came from an alias, a dependency, or an explicit modprobe.

Then rebuild the initramfs so the rule is in force during early boot as well, and reboot:

Configuration changerebuild initramfs— Both blacklist and install live in /etc/modprobe.d/, which is copied into the initramfs when it is built. Until the initramfs is regenerated it carries the OLD copy, so a module can still be loaded during early boot before the new rule exists. Verify after the reboot with 'lsmod | grep usb_storage' (empty) and 'modprobe -v usb-storage' (which should report install /bin/false and load nothing).

$ sudo update-initramfs -u   # Debian family; use 'sudo dracut -f' on RHEL family

Illustrative output

Configuration changeblacklist nouveau— A common production pattern: blacklist the open-source nouveau driver so the proprietary nvidia driver loads cleanly. After updating modprobe.d, regenerate the initramfs (update-initramfs -u on Debian-family; dracut -f on RHEL-family) and reboot.

$ printf 'blacklist nouveau
blacklist nvidia
' | sudo tee /etc/modprobe.d/blacklist-nouveau.conf; sudo update-initramfs -u; sudo reboot

Illustrative output

Investigating module load failures

Read-only / Safemodprobe -v— modprobe -v shows the dependencies it tries to load. A failure at any dependency is reported. The kernel log (journalctl -k) shows the actual loading attempt and the reason for failure — usually a missing symbol (vermagic mismatch) or a missing firmware file.

$ sudo modprobe -v some_module 2>&1; journalctl -k --since '1 minute ago' --no-pager | tail

...

Illustrative output

Common module load failures:

Symptom	Cause	Fix
“Exec format error”	Module built for a different kernel	Install the matching kernel-modules package
“Unknown symbol”	Module references a symbol not in the kernel	Update the module or downgrade the kernel
“No such file or directory”	Module file missing	Install the package that provides it
“Device or resource busy”	Module in use	Stop the dependent service first

Listing modules

Module dependencies

Loading and unloading

modprobe.d — module configuration

Loading a module at every boot

Blacklisting

blacklist is not a disable switch

Investigating module load failures

Knowledge check