Kernel Modules

Even though the Linux kernel is monolithic, a large part of it — hardware drivers especially — is built as separate pieces that can be loaded only when needed. This means the kernel does not have to keep a driver for every conceivable device sitting in memory at all times: a module loads only once matching hardware is detected, or once a user or another module explicitly asks for it.

This article continues directly from The Boot Process and GRUB: once the kernel is running, this is how its internal, swappable pieces are managed.

What You Will Learn

By the end of this article you will be able to:

explain what a kernel module is and why it exists as a separate file at all;
read the list of currently loaded modules with lsmod;
explain the difference between modprobe and insmod/rmmod;
configure a module to load automatically on every boot, or block it from loading at all;
diagnose a module-related problem using dmesg and modinfo.

What a Module Is

A kernel module is a file with a .ko (kernel object) extension that can be added to, or removed from, a running kernel. Network card drivers, filesystem implementations (vfat, nfs), and virtualization components (kvm) are almost all delivered this way, as modules rather than code compiled directly into the kernel image.

find /lib/modules/$(uname -r) -name '*.ko*' | head -n 5

This lists a handful of the module files available for the currently running kernel. $(uname -r) expands to the running kernel's version string — modules are stored in a directory tied to that exact version, because a module built for one kernel version generally will not load into a different one.

Viewing Loaded Modules

lsmod

Sample output:

Module                  Size  Used by
nf_tables             233472  10
vfat                   20480  1
fat                    86016  1 vfat

Module — the module's name;
Size — how much memory it currently occupies;
Used by — the count and names of other modules or processes depending on it. The 1 vfat shown for fat means the vfat module depends on fat, so fat cannot be removed while vfat is still loaded.

For details on a specific module:

modinfo vfat

modinfo reports the module's file location, version, dependencies, and supported parameters — it loads or changes nothing, which makes it a safe way to inspect a module before touching it.

Loading a Module: `modprobe` vs `insmod`

Command	What it does	Resolves dependencies
`modprobe <name>`	Finds a module by name and loads it	Yes — automatically loads any modules it depends on first
`insmod <path>.ko`	Loads a module directly from an explicit file path	No — fails if a dependency isn't already loaded

In practice, modprobe is used almost exclusively, because it consults the dependency list in /lib/modules/$(uname -r)/modules.dep and loads every required module in the correct order automatically.

sudo modprobe vfat
lsmod | grep vfat

insmod is mostly reserved for special cases — testing a single .ko file directly, for example when developing or debugging a new driver.

Removing a Module

sudo modprobe -r vfat

or

sudo rmmod vfat

modprobe -r tries to remove the module along with any dependency modules that nothing else needs anymore. rmmod removes only the module named, nothing else.

Warning

Trying to remove a module that is actively in use — for example, the driver behind a currently mounted filesystem — produces a "Module is in use" error, or in some cases can affect system stability. Check the Used by column in lsmod first.

Loading a Module Automatically at Boot

A module that should load automatically on every boot is listed in a .conf file under /etc/modules-load.d/:

echo "vfat" | sudo tee /etc/modules-load.d/vfat.conf

This is a plain text file containing one module name. The systemd-modules-load service reads these directories at boot and loads whatever is listed there.

Passing Parameters to a Module

Many modules accept options that change their behaviour — modinfo -p <name> lists the ones a given module supports. A parameter can be set for the current load right on the modprobe command line:

sudo modprobe <module> <parameter>=<value>

To make a parameter permanent, write it into an options line under /etc/modprobe.d/:

echo "options <module> <parameter>=<value>" | sudo tee /etc/modprobe.d/<module>.conf

The value actually in effect for a loaded module can be read back from sysfs:

cat /sys/module/<module>/parameters/<parameter>

Warning

modprobe <module> param=value only takes effect if the module is not already loaded — modprobe silently does nothing when the module is present, so the parameter is quietly ignored. To change a parameter on a loaded module, remove and reload it (modprobe -r then modprobe); for a module baked into the initramfs, set the options line and rebuild with update-initramfs -u so the value is in place before the module loads at boot.

Blocking a Module (Blacklisting)

Sometimes a specific module must be prevented from loading automatically — for example, when an incompatible driver is causing problems. This is what the blacklist mechanism is for:

echo "blacklist nouveau" | sudo tee /etc/modprobe.d/blacklist-nouveau.conf

Danger

Blacklisting stops the module from loading automatically going forward, but it does not unload a module that is already loaded right now — it only affects future loads. Before blacklisting a video or network driver, understand the consequences (for example, losing console access); on a production server, only try this kind of change when an alternative console path (such as IPMI) is available.

Blacklisting sometimes also requires refreshing the initramfs, since some modules are baked directly into it:

sudo update-initramfs -u

Diagnosing a Module Problem

sudo modprobe vfat
dmesg | tail -n 20

dmesg shows the kernel's message ring buffer — if loading a module fails (missing hardware, a version mismatch), the reason usually shows up here.

Filtering kernel messages related to a specific module:

dmesg | grep -i vfat

Common Mistakes

Using `insmod` Instead of `modprobe`

insmod does not resolve dependencies. If the module depends on another module that isn't already loaded, insmod fails with an "unknown symbol" error. For ordinary use, modprobe should always be the default choice.

Removing a Module Without Checking `Used by`

If another module or an active mount depends on it, removal either fails outright or, in some cases, leads to unexpected behavior.

A Blacklisted Module Still Loading

The module may already be baked into the initramfs. In that case, writing to /etc/modprobe.d/ alone is not enough — update-initramfs -u is also required.

Exercises

Pick three modules from lsmod output and use modinfo to find each one's description and dependencies.
In a disposable VM, remove a harmless module (e.g. vfat) with modprobe -r, confirm with lsmod, then load it back with modprobe.
Create a permanent load file for that module under /etc/modules-load.d/ and confirm with lsmod after a reboot (test VM only).
Search dmesg output for recent messages mentioning "module" and identify which module each one refers to.

Verification criterion: you should be able to explain, for any module currently in lsmod, what removing it would require checking first.

Summary

Kernel modules let functionality like drivers and filesystem support be added to, or removed from, a running kernel. lsmod shows the current state, modinfo shows details about a specific module; modprobe loads or removes modules while resolving dependencies, while insmod/rmmod act on an exact file directly. Automatic loading is configured through /etc/modules-load.d/, and blocking through /etc/modprobe.d/. For deeper boot-related failures, the next relevant article is Rescue and Emergency Mode.