Load and Verify Linux Kernel Modules

modprobe is the normal administrative interface for adding an installed module to the running kernel. It uses dependency information and configuration to load supporting modules first. Loading a module is a runtime operation; it does not recompile the kernel.

Inspect, load, and verify

In a disposable lab, inspect the loop-device driver before requesting it. This example assumes that the driver is available as a loadable module. If your kernel builds it in, it will not appear in lsmod.

modinfo loop
modprobe --show-depends loop
sudo modprobe -v loop
lsmod | grep '^loop '
sudo journalctl -k -b --no-pager

A successful modprobe may print nothing. It may also succeed when the module was already loaded. Use the loaded-module list and the actual device or feature behavior to check the result. Kernel log messages help explain missing dependencies, incompatible code, or signature rejection.

Do not confuse a module that is available on disk with one listed by lsmod. The latter reports loaded modules, not every driver that could be used.

Know what each tool does

• modprobe loads by module name and resolves dependencies.
• insmod inserts a specified module file without automatically loading its dependencies. It is useful for controlled development work.
• modprobe -r requests removal and handles eligible dependencies.
• rmmod removes a module directly; it is not a loading command.
• depmod builds dependency metadata; it does not insert a module.

Remove only an unused module

Unload a lab module only after stopping its users. For the loop driver, check for loop devices first:

losetup --list
# Only after confirming the lab module has no active users:
sudo modprobe -r loop

Removal can fail because a module is in use, another module depends on it, or unloading is not supported. Do not force removal of storage or network drivers serving an active system. A built-in driver cannot be unloaded this way.

How modules become available automatically

Device events, userspace device management, and requests from kernel subsystems can cause the appropriate module to be loaded. Administrators normally let this mechanism handle hardware discovery. For a specific module that must be requested at startup, a configuration file under /etc/modules-load.d/ can list its name; the next lesson explains that distinction.

The userspace kmod tools should not be described as a continuously polling kernel thread. Automatic loading also does not mean that every installed module will load at each reboot.

Conceptual loading sequence

These illustrations show code being added to an existing kernel. The added code executes in kernel space.

If loading fails

Compare uname -r with the installed module release, verify that the needed package is installed, and read the kernel log. With signature enforcement enabled, an unsigned or untrusted module can be rejected. Follow the distribution's signing and enrollment process rather than bypassing verification to hide the error.

The next lesson explains persistent module options and boot-time configuration.

References

• kmod manual: modprobe
• RHEL 10: Managing kernel modules
• Linux kernel documentation: Module signing