Managing Linux kernel modules with modprobe and lsmod

Kernel modules form the backbone of flexible Linux systems, allowing drivers and features to load or unload without recompiling the kernel. Whether the host is a CentOS server in a Brisbane datacentre or a Fedora workstation in a Perth engineering firm, managing these modules cleanly affects stability after every kernel update.

The two commands at the centre of this work are modprobe and lsmod. They handle the loading, dependency resolution, and inspection of modules, which makes them essential for anyone running RHEL-family distributions in Australian enterprise environments.

This walkthrough covers the practical commands, how dependencies are tracked, and how to fine-tune persistent loading behaviour for production hosts and home labs alike.

How kernel modules sit inside a running system

A module is a piece of compiled code inserted into the running kernel on demand. It talks directly to hardware or to internal kernel subsystems, which is why network cards, filesystems, and virtualisation drivers all rely on this mechanism. On RHEL-based systems modules live under /lib/modules/$(uname -r)/, grouped by the kernel release currently booted.

The modprobe command delegates to a userspace helper that reads the dependency map and loads prerequisite modules in the right order. Without that orchestration, modules that depend on each other — such as a wireless driver needing firmware loading support — would fail with cryptic symbol errors. Many Australian administrators rely on this dependency-aware behaviour to keep vendor drivers working after major kernel upgrades.

Reading the loaded set with lsmod

lsmod lists every module currently sitting inside the kernel. The output is a three-column table showing the module name, its size, and a count of how many other modules depend on it.

A non-zero count in the third column means removing the module will pull other modules down with it. For example, nfsv4 651345 1 nfs shows nfsv4 is used by one instance of nfs; removing it would interrupt mounted filesystems, which is worth avoiding before any maintenance window. The data is read from /proc/modules, so it always reflects the live kernel state, not the configured-to-load list.

Pairing lsmod with modinfo module_name shows the version, the source file, and any parameters the module accepts.

Loading modules with modprobe

To insert a new module, modprobe module_name is usually enough. Unlike insmod, it walks the dependency map and pulls in prerequisites automatically, which removes a common cause of "unknown symbol" errors on fresh servers.

The command also honours files in /etc/modprobe.d/. Any .conf placed there influences how modules load on that system, which is how administrators apply vendor recommendations from companies like IBM, Red Hat, and Dell for enterprise hardware shipped into Australian offices.

When a proprietary driver must be built outside the standard repos — for instance, over a slower nbn link in a regional town — placing the resulting .ko file under /lib/modules/$(uname -r)/extra/ and running depmod first lets modprobe find it cleanly.

Removing modules with modprobe -r

Unloading follows dependency logic in reverse. modprobe -r module_name checks what depends on the target and refuses to remove anything still in use, which is why it is preferred over rmmod for routine work.

Before unloading, lsmod should show a usage count of zero. The consumer can often be located with lsof or by scanning dmesg. On a Canberra mail host, for example, removing ipv6 while Postfix still binds an IPv6 socket would break delivery, so checking first is essential. A forced removal is possible with modprobe -r --force, though newer RHEL kernels log warnings about the resulting instability.

Persistent options, aliases, and blacklisting

modprobe supports more than one-off commands. Options pass through files in /etc/modprobe.d/, such as options module_name parameter=value. Aliases give modules friendlier names, useful when vendors expect a specific device string at boot.

Blacklisting prevents a competing driver from claiming a device; adding blacklist driver_name to a .conf file ensures modprobe skips it during auto-load. A rebuild of the initramfs via dracut --force is usually required for the change to survive a reboot on RHEL-family systems.

This persistence matters on laptops used by consultants who frequently dock and undock at client sites around Sydney and Adelaide, where the same hardware may need different module behaviour depending on which peripherals are attached. The broader publication also touches on topics that have nothing to do with kernels, including a recent online gambling article that sits alongside the technical guides.

modprobe and lsmod cover nearly every routine task on a Linux host. Combined with /etc/modprobe.d/, they let drivers load on demand, the running set get inspected, and kernel behaviour shape itself across reboots without touching source code. When something environment-specific blocks progress, the contact-us page is the quickest path to tailored advice for the distribution and kernel version in use.