🧩 Managing Linux Kernel Modules with modprobe, lsmod, and modinfo

Kernel modules are how Linux loads drivers and optional features without compiling a monolithic kernel. Most of the time they just work — a disk shows up, the NIC comes online, nobody thinks about it. But when you need to load a driver by hand, blacklist a module that’s grabbing the wrong device, or pass an option to a driver, the module subsystem becomes very relevant very fast. Here’s the working knowledge I reach for.

Inspecting what’s loaded

Start with what’s currently in the kernel:

lsmod                    # all loaded modules, sizes, and what uses them
lsmod | grep nvme        # is the nvme driver loaded?

The third column of lsmod — “Used by” — is the dependency chain. A module with a non-zero use count can’t be unloaded until its dependents are gone, which explains a lot of “module is in use” errors.

To learn about a module before touching it:

modinfo e1000e           # description, author, parameters, dependencies
modinfo -p e1000e        # just the parameters it accepts

modinfo -p is the one to remember — it tells you exactly which options a driver supports, so you’re not guessing at parameter names.

Loading and unloading

modprobe is the tool you want, not the lower-level insmod, because modprobe resolves dependencies automatically:

sudo modprobe nvme           # load nvme and anything it needs
sudo modprobe -r nvme        # remove it (and unused deps)

insmod/rmmod exist but don’t handle dependencies, so use them only for deliberate single-file experiments. To check whether a module even exists for your running kernel:

modprobe -n -v nvme          # dry run: show what WOULD load, don't load it

The dry-run flag is a nice safety check before you commit on a production box.

Passing options to a module

Some drivers take parameters. You can pass them at load time:

sudo modprobe i915 enable_guc=2

For persistence, drop a file in /etc/modprobe.d/:

# /etc/modprobe.d/i915.conf
options i915 enable_guc=2

After editing anything in /etc/modprobe.d/, the change applies on next load — but if the module is already built into the initramfs, you also need to rebuild it (covered below). Inspect current parameter values of a loaded module under /sys:

cat /sys/module/i915/parameters/enable_guc

That /sys/module/<name>/parameters/ tree is the authoritative view of what a loaded module is actually using.

Blacklisting a module

A common real-world need: a module keeps grabbing a device you want a different driver (or userspace tool) to own, or a flaky driver crashes the box. Blacklist it:

# /etc/modprobe.d/blacklist-nouveau.conf
blacklist nouveau
install nouveau /bin/false

The blacklist line stops it from auto-loading by alias; the install ... /bin/false line is the belt-and-suspenders version that prevents it from loading even when pulled in as a dependency. Both are often needed for stubborn modules like nouveau when installing proprietary GPU drivers.

Blacklisting only takes full effect after you regenerate the initramfs, because early-boot modules live there.

The initramfs gotcha

This trips up everyone once. Modules needed early in boot (storage controllers, root filesystem drivers) are baked into the initramfs. Editing /etc/modprobe.d/ does not change what’s already in the initramfs. So after blacklisting or reconfiguring an early-boot module, rebuild it:

# Debian/Ubuntu
sudo update-initramfs -u

# RHEL family
sudo dracut -f

Forgetting this step is why “I blacklisted it but it still loads on boot” happens. The blacklist worked — the initramfs still had the old config.

Auto-loading a module at boot

The inverse: you want a module loaded every boot. List it in /etc/modules-load.d/:

# /etc/modules-load.d/br_netfilter.conf
br_netfilter

systemd-modules-load.service reads these at boot. This is the clean, declarative way — far better than stuffing modprobe into rc.local.

Troubleshooting a module that won’t load

When modprobe foo fails, the kernel ring buffer almost always says why:

sudo modprobe foo
dmesg | tail -20         # the actual error: missing symbol, signature, hardware

Common causes: the module isn’t built for your running kernel (after a kernel upgrade without a reboot, /lib/modules/$(uname -r) may not match), a Secure Boot signature rejection, or a hardware/firmware dependency. Check the kernel version alignment:

uname -r
ls /lib/modules/$(uname -r)/kernel/drivers/

If /lib/modules/$(uname -r) doesn’t exist, you upgraded the kernel package but are still running the old kernel — reboot or install the matching modules.

A quick reference

Task	Command
List loaded	lsmod
Inspect a module	modinfo <mod>
Load with deps	modprobe <mod>
Unload	modprobe -r <mod>
Options at load	modprobe <mod> opt=val
Persistent options	/etc/modprobe.d/*.conf
Blacklist	blacklist + install <mod> /bin/false
Auto-load at boot	/etc/modules-load.d/*.conf
After early-boot changes	update-initramfs -u / dracut -f

Where AI helps

modinfo parameter lists and dmesg load failures are full of cryptic symbol names and signature errors. Pasting the failed modprobe plus the dmesg tail into a model and asking “why won’t this load and what’s the safe fix” usually pinpoints whether it’s a kernel mismatch, a Secure Boot issue, or a missing dependency. I keep a few Linux admin prompts for exactly this.

The module system is small and learnable. Know modinfo before you load, modprobe over insmod, and never forget the initramfs rebuild after a blacklist — and the kernel stops surprising you on boot.

Generated commands and configs are assistive, not authoritative. Always verify against your own systems before applying changes in production.