Lesson 3	Inspect Installed and Loaded Linux Kernel Modules
Objective	Use uname, lsmod, modinfo, and module directories to distinguish available, loaded, and built-in functionality.

Inspect Installed and Loaded Linux Kernel Modules

Three questions often get confused: which kernel is running, which modules are installed for it, and which modules are loaded now. Answer them separately before investigating a missing driver or changing configuration.

Identify the running kernel

uname -r
ls /lib/modules

Each installed kernel release has its own module directory. On systems with a merged /usr layout, /lib may resolve into /usr/lib. Do not rename or combine release directories: a module built for another kernel cannot be assumed compatible with the running one.

List what is loaded

lsmod
cat /proc/modules

lsmod formats the running kernel's module list. Its usual columns identify the module, its size, and a usage count, with dependent module names where available. The usage count is not a count of devices or applications, and the size column is not a benchmark of the driver's efficiency.

Built-in drivers are absent from lsmod. A missing row can also mean that an installed module has not been requested. Therefore, an empty search result alone does not show that support is unavailable.

$ lsmod
Module                  Size  Used by
bridge                192512  0
stp                    16384  1 bridge
llc                    16384  2 bridge,stp

Example excerpt in the current lsmod format. Module names, sizes, and usage counts vary by system.

Read dependency names from the row they appear on: bridge uses stp, while both bridge and stp use llc. A usage count of zero does not by itself establish that unloading a module is appropriate.

Inspect a module before loading it

The following examples use loop, the loop-device driver. Availability and packaging depend on the kernel configuration; if it is built in, there may be no loadable file for it.

modinfo loop
modinfo -F filename loop
modinfo -F depends loop
modinfo -p loop

Read the description, parameters, dependency information, and filename. A module file commonly ends in .ko, possibly followed by a compression suffix. Pass the module name to modprobe; you do not normally need to locate or decompress the file yourself.

To inspect another installed kernel, explicitly select its release:

# Replace this example value with the exact installed target release.
target_release='REPLACE_WITH_INSTALLED_KERNEL_RELEASE'
modinfo -k "$target_release" loop

That command inspects metadata for the selected kernel. It does not load its code into the currently running kernel.

Inspect installed files when needed

find "/lib/modules/$(uname -r)" -type f -name '*.ko*'
ls "/lib/modules/$(uname -r)/modules.builtin"

The file list and built-in metadata answer different questions. modules.dep and its binary counterpart support dependency resolution and are generated by depmod; they are not files to maintain manually.

A useful troubleshooting order

Confirm the running release with uname -r.
Check whether the feature is built in or provided by an installed module.
Inspect its parameters and dependencies.
Only then attempt to load it and inspect the kernel log if loading fails.

The next lesson covers loading, unloading, and verification.

References