The kernel and modules

Before you read. Linux runs on a laptop, a phone, a router, a mainframe, and a car. It supports tens of thousands of different devices, every network card, every disk controller, every webcam anybody has bothered to write support for.

All of that support cannot be loaded into memory at once; it would be gigabytes. But it also cannot be left out, because then the kernel would only work on hardware it was specifically built for.

So: how does one kernel support hardware nobody had invented when it was compiled, without carrying the weight of all of it?

The answer is that the kernel is not one thing. It is a small core plus a large pile of loadable pieces, and it loads the pieces it needs when it meets the hardware that needs them.

That design is the reason “I plugged it in and it worked” happens at all, and it is also the reason a handful of specific things go wrong in a way that looks like broken hardware.

Some words you will need

kernel

The program that owns the hardware. Everything else asks it for access to memory, disks, and the network.

module

A piece of kernel code that can be loaded and unloaded while the machine is running. Most drivers are modules.

driver

Code that knows how to talk to one kind of hardware. On Linux, usually delivered as a module.

filesystem module

Not all modules are drivers. Filesystem support, network filtering, and encryption are modules too.

What breaks without this

Hardware that “is not there”. A card is fitted, the machine sees nothing, and there is no error anywhere obvious. The module for it did not load, and no part of the system considers that worth complaining about.

A machine that stops seeing its own disks after an update. Modules are tied to a kernel version. Anything not built by the distribution has to be rebuilt for each new kernel, and when it is not, the failure arrives at the next reboot.

A driver you cannot get rid of. Two modules claim the same device, the wrong one wins, and until you know how to refuse a module by name you are stuck with whichever one loaded first.

What is actually loaded

# Fedora CoreOS 44.20260707.3.1 on a virtual machine, aarch64
$ lsmod | head -8; echo "---"; lsmod | wc -l
Module                  Size  Used by
raid1                  65536  0
loop                   36864  0
nft_ct                 24576  1
nft_fib_inet           12288  2
nft_fib_ipv4           12288  1 nft_fib_inet
nft_fib_ipv6           12288  1 nft_fib_inet
nft_fib                12288  3 nft_fib_ipv6,nft_fib_ipv4,nft_fib_inet
---
65

Sixty-five modules on a machine doing very little. Three columns:

• Module, the name, which is what every other command in this lesson takes.
• Size, bytes of kernel memory it occupies.
• Used by, a count, and then the names of whatever is using it.

That third column is the useful one. nft_fib shows 3 and then names three modules that depend on it. A module with a non-zero count cannot be unloaded until whatever is using it lets go, which is the answer to most of “why will this not unload”.

Notice what is in that list. raid1 is not a driver for a piece of hardware; it is software RAID. nft_* are the firewall. Modules are not only drivers, and expecting them to be leads to confusion the first time you meet one that is not.

What a module is and where it came from

# Fedora CoreOS 44.20260707.3.1 on a virtual machine, aarch64
$ modinfo xfs | head -9
filename:       /lib/modules/7.1.3-200.fc44.aarch64/kernel/fs/xfs/xfs.ko.xz
license:        GPL
description:    SGI XFS with ACLs, security attributes, realtime, scrub, repair, quota, no debug enabled
author:         Silicon Graphics, Inc.
alias:          fs-xfs
depends:        
intree:         Y
name:           xfs
vermagic:       7.1.3-200.fc44.aarch64 SMP preempt mod_unload aarch64

Read four of those lines closely, because they carry the whole model.

filename puts the module under /lib/modules/<kernel version>/. That path is the most important thing on the page: modules live in a directory named after the kernel they belong to. A machine with three kernels installed has three of those directories.

depends lists other modules this one needs. Empty here; often not. modprobe reads this so you never have to load dependencies by hand.

intree: Y means it ships with the kernel. N would mean it came from somewhere else, and that is the set you have to think about at every update.

vermagic is the version stamp, and it is checked at load time. If it does not match the running kernel exactly, the module is refused. Not warned about, refused.

modinfo e1000e | grep ^alias | head -3
cat /lib/modules/$(uname -r)/modules.alias | wc -l

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

sudo dracut -f              # RHEL family
sudo update-initramfs -u    # Debian family

Loading and unloading

The dummy module is counted, loaded, listed, unloaded, and counted again. Note the third column of lsmod output while it is loaded. That is the use count.

# Fedora CoreOS 44.20260707.3.1 on a virtual machine, aarch64
$ lsmod | grep -c dummy; sudo modprobe dummy; lsmod | grep dummy; sudo modprobe -r dummy; lsmod | grep -c dummy
0
dummy                  12288  0
0

Zero, which is why the unload worked. The kernel refuses to remove a module whose use count is above zero, so modprobe -r on a driver with a mounted filesystem or an up interface fails with Module ... is in use, and the fix is never to force it but to stop whatever is using it. The third column is the first thing to read when an unload is refused.

Not loaded, loaded, not loaded. Three states in one line.

Prefer modprobe over insmod and rmmod. The older pair take a file path and ignore dependencies entirely; modprobe takes a name, resolves dependencies, and searches the right directory for the running kernel. The exam mentions both; in practice modprobe is the answer.

Ask for something that does not exist and the message is unusually clear:

# Fedora CoreOS 44.20260707.3.1 on a virtual machine, aarch64
$ sudo modprobe notarealmodule; ls /etc/modprobe.d/ 2>/dev/null || echo "(empty)"; ls /usr/lib/modprobe.d/ | head -5
modprobe: FATAL: Module notarealmodule not found in directory /lib/modules/7.1.3-200.fc44.aarch64
blacklist-nouveau.conf
dist-blacklist.conf
systemd.conf

It names the directory it searched, and that directory has the kernel version in it. When this message appears for a module you are sure exists, read the version in the path. It is very often a module built for a different kernel, or a depmod that was never run.

Making a choice persist

Loading a module by hand lasts until reboot. Two directories make it permanent:

Note the two directories in the capture above. /usr/lib/modprobe.d/ is the distribution’s and /etc/modprobe.d/ is yours; yours wins. The file blacklist-nouveau.conf shipping by default is a real example of the pattern: nouveau is the open-source NVIDIA driver, and it is blacklisted so it does not grab the card before the proprietary one gets a chance.

Blacklisting is not absolute. It stops the module being loaded automatically as a dependency or by device detection; an explicit modprobe nouveau still works. To refuse it outright you need install nouveau /bin/false instead, which is the distinction the exam likes.

ls /sys/module/nvme/parameters/
cat /sys/module/nvme/parameters/poll_queues

Where modules come from

# Fedora CoreOS 44.20260707.3.1 on a virtual machine, aarch64
$ uname -r; ls /lib/modules/; ls /lib/modules/$(uname -r)/kernel/fs | head -8
7.1.3-200.fc44.aarch64
7.1.3-200.fc44.aarch64
9p
afs
binfmt_misc.ko.xz
cachefiles
ceph
dlm
ecryptfs
erofs

One kernel installed, so one directory, and its name is exactly what uname -r prints. Under it, the tree is organised by subsystem: kernel/fs/ for filesystems, kernel/drivers/ for hardware, kernel/net/ for networking.

uname -r is the command to reach for constantly. It answers “which kernel is running”, which is the first half of nearly every module question. uname -a gives the same plus architecture and build date.

And the loading happens without you:

# Fedora CoreOS 44.20260707.3.1 on a virtual machine, aarch64
$ sudo dmesg | grep -i "virtio_blk\|virtio_net" | head -5; echo "--- /sys ---"; ls /sys/class | head -12
[    0.068159] virtio_blk virtio2: 1/0/0 default/read/poll queues
[    0.068472] virtio_blk virtio2: [vda] 209715200 512-byte logical blocks (107 GB/100 GiB)
[    1.778543] virtio_net virtio0 enp0s1: renamed from eth0
--- /sys ---
accel
ata_device
ata_link
ata_port
backlight
bdi
block
bsg
devcoredump
devfreq
devfreq-event
devlink

Three lines from the kernel log, all in the first two seconds. The block driver loaded and announced a 100 GiB disk called vda. The network driver loaded and renamed the interface from eth0 to enp0s1, that rename is predictable interface naming, and it is why the interface on a modern machine is not called what you expect. It comes back in the networking lessons.

Nobody typed modprobe. The kernel saw the hardware, looked up which module claims it, and loaded it. dmesg is where you go to find out whether that happened.

Across distributions

You will also meet mkinitrd. On current RHEL-family systems it is a small wrapper that calls dracut, kept so that old documentation and old scripts keep working, and on some other distributions it was the tool in its own right before dracut existed. The objectives name both, and knowing that one is a compatibility shim for the other is the whole of the difference. | Kernel package | kernel, kernel-core | linux-image-* |

Those first two rows look like a difference and are not one. Since the usr-merge of lesson 04, /lib is a symlink into /usr/lib on both families, so /lib/modprobe.d and /usr/lib/modprobe.d are the same directory reached by two names. Documentation written before the merge still uses the short form, which is why you meet both spellings and why neither is wrong.

The commands are the same everywhere; this is one of the more portable corners of Linux. Debian’s older /etc/modules still works and still appears in documentation, but /etc/modules-load.d/ is the systemd-era answer and is understood on both.

Prove it

After loading, blacklisting, or updating a module:

# Is it loaded, and is anything using it
lsmod | grep thename

# Which file would load, and for which kernel
modinfo thename | head -3

# Did the kernel say anything when it loaded
sudo dmesg | grep -i thename | tail

# Will the choice survive a reboot
grep -r thename /etc/modprobe.d/ /etc/modules-load.d/

That last one is the check people skip. A module loaded by hand and a module loaded at boot look identical in lsmod, and only one of them is still there tomorrow.

What trips people up

1. “Module not found in directory /lib/modules/…”

Read the version in that path and compare it to uname -r. Three common causes:

• The module was built for a different kernel. Common after an update, when the machine booted a new kernel and the module was built against the old one.
• depmod was never run after a module was copied in by hand.
• The module genuinely is not installed. It is in an optional package such as kernel-modules-extra on the RHEL family.

2. “Module is in use” when unloading

rmmod: ERROR: Module xyz is in use. Look at the third column of lsmod: it names what is holding it.

Unload the dependants first, or use modprobe -r, which does that for you. If the user count is non-zero with no names listed, something has the device open, a mounted filesystem, a configured interface, a running process.

3. It worked until the kernel was updated

The classic. Anything out-of-tree has to be rebuilt per kernel, and vermagic enforces it.

Boot the previous kernel from the GRUB menu to confirm, then fix it properly with DKMS so it rebuilds itself next time. Do not fix it by pinning the kernel and never updating; that trades a driver problem for a security problem.

4. Blacklisting and being surprised it still loads

blacklist prevents automatic loading, not explicit loading, and not loading as a dependency of a module that lists it under install. If something must never load, install thename /bin/false is the stronger form.

And if the module loads during boot before userspace exists, the blacklist has to be in the initramfs too, which means rebuilding it.

5. Assuming every module is a driver

raid1, nft_ct, dm_crypt, xfs, overlay, software subsystems, all of them modules. Unload one thinking it is a driver for absent hardware and you have taken away the firewall, or the ability to mount a filesystem.

Check modinfo’s description line before unloading anything you did not load yourself.

Work it through

A server has a vendor storage card. It has worked for a year. The machine was patched and rebooted at the weekend, and it now boots to an emergency shell saying it cannot find the root filesystem.

You boot the previous kernel from the GRUB menu and everything works perfectly.

Reason it out before reading on.

Booting the old kernel fixes it, so the hardware is fine. So is the disk, the data, the partition table, and the bootloader, all of those are the same on both kernels. The variable is the kernel.

What differs between kernels? The module directory. /lib/modules/<old>/ and /lib/modules/<new>/ are separate trees, and a module in one is not in the other. The vendor’s driver was installed once, into the tree that existed at the time.

Why an emergency shell rather than a boot with one missing card? Because this card holds the root filesystem. From the last lesson: the initramfs has to load whatever is needed to reach root. It could not, so stage 4 gave up. Had the card held only a data volume, the machine would have booted and the volume would simply have been absent, a much quieter and arguably worse failure.

Confirm it. From the working boot: modinfo thedriver | grep -E 'filename|vermagic' shows which kernel it belongs to, and dkms status shows whether anything is registered to rebuild it. An empty dkms status is the finding.

The fix. Install the driver under DKMS so it builds for every kernel, then rebuild the initramfs for the new kernel with dracut -f --kver <new>, then reboot deliberately.

Now the question underneath: why did the kernel update succeed and report no problem? Because from the package manager’s point of view nothing was wrong. It installed a kernel. It has no idea which of the modules on the machine came from outside the distribution, and the module that would have complained never ran. It was never built.

The habit worth taking: on any machine with out-of-tree drivers, dkms status belongs in the pre-reboot checklist, next to checking that /boot has room.

Try it

Optional, if you have a machine handy.

1. uname -r, then ls /lib/modules/. Say how many kernels are installed.
2. lsmod | wc -l, then lsmod | head. Find a module with a non-zero use count and name what is using it.
3. modinfo on one of them. Say whether it is in-tree and which kernel it is for.
4. sudo modprobe dummy, confirm with lsmod | grep dummy, then sudo modprobe -r dummy. Harmless, and it creates nothing you have to undo.
5. ls /etc/modprobe.d/ /usr/lib/modprobe.d/ and read any blacklist file you find. Work out what it is protecting against.
6. sudo dmesg | head -40 and find the point where the storage driver loaded.

Verification step. You have it when you can take a device that is not working and say, in order, whether the module exists, whether it loaded, and whether anything stopped it.

Check yourself

References

• modprobe(8) - Linux man-pages project. Accessed 2026-08-07.
• lsmod(8) - Linux man-pages project. Accessed 2026-08-07.
• modinfo(8) - Linux man-pages project. Accessed 2026-08-07.
• depmod(8) - Linux man-pages project. Accessed 2026-08-07.
• modprobe.d(5) - Linux man-pages project. Accessed 2026-08-07.
• uname(1) - Linux man-pages project. Accessed 2026-08-07.

Command output was captured on the podman machine, which has a real kernel; a container borrows the host’s and has no modules of its own. Blocks without a distribution and architecture header are illustrative.