Kahibaro
Discord Login Register ☰
☰
Previous
Up
Next

4.3.2 Kernel modules

Table of Contents

Understanding Kernel Modules

A kernel module is a piece of code that can be loaded into (and unloaded from) the running Linux kernel at runtime, without rebooting and without recompiling the whole kernel.

Typical examples of functionality provided as modules:

Modules allow you to:

In this chapter you will learn how to inspect, load, unload, configure and persist kernel modules on a running system.

Listing and Inspecting Loaded Modules

Viewing all loaded modules with `lsmod`

lsmod shows you which modules are currently loaded: 

lsmod

Sample output: 

Module                  Size  Used by
iwlwifi               335872  1 iwlmvm
iwlmvm                458752  0
uvcvideo              102400  0
snd_hda_intel          49152  4

Key columns:

If a module is “in use”, unloading it will usually fail until users or dependent modules are stopped or removed.

Detailed information with `modinfo`

Use modinfo to inspect information about a specific module: 

modinfo iwlwifi

Typical fields: 

  parm: debug:Enable debug output (bool)
  parm: tx_power:Default TX power (int)

This is how you discover tunable knobs for a module.

Loading and Unloading Modules

Loading modules with `modprobe`

modprobe is the standard tool for loading modules. It understands dependencies and configuration files.

Basic usage: 

sudo modprobe MODULE_NAME

Examples: 

  sudo modprobe vfat
  sudo modprobe e1000e

modprobe will:

You can test without making persistent changes; a reboot will remove non-built-in modules unless configured to load automatically.

`insmod` vs `modprobe`

insmod is a low-level tool that inserts a single module file: 

sudo insmod ./mymodule.ko

Limitations:

This is mainly useful for debugging or testing your own freshly built module. For normal administration, always prefer modprobe.

Removing modules with `modprobe -r` and `rmmod`

To unload a module: 

sudo modprobe -r MODULE_NAME

or: 

sudo rmmod MODULE_NAME

modprobe -r is safer:

Unloading can fail with errors like:

You can check usage with: 

lsmod | grep MODULE_NAME

The second column (Used by) should be 0 before unloading.

Kernel Module Files and Locations

Modules are stored under: 

/lib/modules/$(uname -r)/

Useful subdirectories:

You normally don’t manipulate these files directly. Package management and depmod manage them for you.

You can search for a module file with: 

modinfo -n MODULE_NAME

or: 

find /lib/modules/$(uname -r) -name 'e1000e*.ko*'

depmod (usually run automatically on kernel or module package updates) generates dependency metadata like:

modprobe relies on these.

Module Parameters

Modules often expose parameters to tune their behavior. These can be set:

Discovering available parameters

Use modinfo and look for parm: lines: 

modinfo snd_hda_intel | grep ^parm

Example output: 

parm:   power_save:Automatic power-saving timeout (in seconds) (int)
parm:   enable_msi:Enable Message Signaled Interrupts (int)

Each parameter has a name, description, and type (e.g. int, bool).

Setting parameters at load time

You can set parameters when loading: 

sudo modprobe snd_hda_intel power_save=10 enable_msi=1

This is temporary; once you unload/reload or reboot, settings are lost unless you make them persistent.

Persistent Module Configuration (`/etc/modprobe.d`)

To keep settings across reboots, use configuration files for modprobe.

Files in: 

/etc/modprobe.d/*.conf

influence loading behavior. Common types of lines:

Setting persistent options

Create a configuration file, e.g.: 

sudo nano /etc/modprobe.d/snd_hda_intel.conf

Add: 

options snd_hda_intel power_save=10 enable_msi=1

Then either: 

  sudo modprobe -r snd_hda_intel
  sudo modprobe snd_hda_intel

Check current behavior (for modules that expose state) under /sys/module/MODULE_NAME/parameters/: 

cat /sys/module/snd_hda_intel/parameters/power_save

For many modules you can change parameters by writing to these files at runtime: 

echo 20 | sudo tee /sys/module/snd_hda_intel/parameters/power_save

This changes the setting until reboot; the config file handles persistence.

Blacklisting Modules

Sometimes you want to prevent a module from being loaded automatically:

Basic blacklisting

Create a file like: 

sudo nano /etc/modprobe.d/blacklist.conf

Add: 

blacklist nouveau

This marks the nouveau module (open-source NVIDIA driver) as blacklisted.

Notes:

To be sure it’s not loaded early in boot, you might also need to:

Replacing a module with another

When using a proprietary driver in place of a default one (e.g., GPU or Wi-Fi), common steps are:

  1. Blacklist the built-in/open-source driver.
  2. Install the new module via your package manager or vendor script.
  3. Regenerate initramfs if needed.
  4. Reboot.

The exact procedure depends on your distribution and driver source.

Module Autoloading

Modules are usually loaded automatically when needed, driven by:

Mechanism outline:

This explains why drivers “just appear” when you plug in a device or boot with new hardware.

You normally don’t need to configure autoloading explicitly, but if something doesn’t load: 

  lspci -nn
  lsusb

and search aliases: 

  grep -i 8086 /lib/modules/$(uname -r)/modules.alias

Security and Stability Considerations

Kernel modules run in kernel space; bugs or malicious behavior can compromise the entire system.

Key points:

The kernel tracks certain conditions as “taints” when modules are loaded, such as:

You can see taint status (among other info) via: 

cat /proc/sys/kernel/tainted

The bitmask interpretation is usually documented in Documentation/admin-guide/tainted-kernels.rst in the kernel source or online.

Working with Out-of-Tree and Custom Modules (Admin View)

The development process for creating modules is covered in other material; here we’ll focus on the administrator’s perspective when dealing with non-standard modules.

Common scenarios:

DKMS-managed modules

DKMS automates rebuilding modules when the kernel is updated.

Typical workflow:

  1. Install DKMS and the module source package from your distribution or vendor.
  2. DKMS registers the module and builds it for your current kernel.
  3. When you upgrade the kernel, DKMS automatically rebuilds the module for the new kernel version.
  4. Module files are placed under /lib/modules/$(uname -r)/extra/ or similar.

As an admin you should: 

  sudo dkms status

Version compatibility

A module must be built against headers for the exact kernel version it runs on:

You can see the compiled-for version via: 

modinfo -F vermagic MODULE_NAME

If your kernel version (uname -r) and vermagic don’t match sufficiently, rebuild or reinstall the module.

Troubleshooting Kernel Modules

Common issues and approaches:

Module fails to load

Run: 

sudo modprobe MODULE_NAME
dmesg | tail

or: 

journalctl -k -b | tail

Typical error messages:

Device not working despite module loaded

Steps:

  1. Confirm module is present:
   lsmod | grep MODULE_NAME
  1. Check dmesg/journalctl -k for initialization errors.
  2. Verify device node appears under /dev (if relevant).
  3. Inspect parameters in /sys/module/MODULE_NAME/parameters/ and adjust via modprobe options or /etc/modprobe.d/.
  4. Look for conflicting modules:
    • Use lsmod to spot multiple drivers for similar hardware.
    • Blacklist the wrong one if needed.

Preventing unwanted autoload

If a problematic module keeps loading:

  1. Identify it with lsmod and dmesg.
  2. Add a blacklist MODULE_NAME line to a file in /etc/modprobe.d/.
  3. Regenerate initramfs if necessary.
  4. Reboot and verify it’s no longer loaded.

Summary

Previous
Up
Next

Views: 95

Comments

Please login to add a comment.

Don't have an account? Register now!

© 2025 Kahibaro

Visitors: 3939 / 24h

Impressum / Imprint

Datenschutz / Data Policy