Menu Close
Chapter 3. Managing kernel modules
The following sections explain what kernel modules are, how to display their information, and how to perform basic administrative tasks with kernel modules.
3.1. Introduction to kernel modules
The Red Hat Enterprise Linux kernel can be extended with optional, additional pieces of functionality, called kernel modules, without having to reboot the system. On Red Hat Enterprise Linux 9, kernel modules are extra kernel code which is built into compressed <KERNEL_MODULE_NAME>.ko.xz
object files.
The most common functionality enabled by kernel modules are:
- Device driver which adds support for new hardware
-
Support for a file system such as
GFS2
orNFS
- System calls
On modern systems, kernel modules are automatically loaded when needed. However, in some cases it is necessary to load or unload modules manually.
Like the kernel itself, the modules can take parameters that customize their behavior if needed.
Tooling is provided to inspect which modules are currently running, which modules are available to load into the kernel and which parameters a module accepts. The tooling also provides a mechanism to load and unload kernel modules into the running kernel.
3.2. Kernel module dependencies
Certain kernel modules sometimes depend on one or more other kernel modules. The /lib/modules/<KERNEL_VERSION>/modules.dep
file contains a complete list of kernel module dependencies for the respective kernel version.
The dependency file is generated by the depmod
program, which is a part of the kmod
package. Many of the utilities provided by kmod
take module dependencies into account when performing operations so that manual dependency-tracking is rarely necessary.
The code of kernel modules is executed in kernel-space in the unrestricted mode. Because of this, you should be mindful of what modules you are loading.
Additional resources
-
modules.dep(5)
manual page -
depmod(8)
manual page
3.3. Listing currently loaded kernel modules
The following procedure describes how to view the currently loaded kernel modules.
Prerequisites
-
The
kmod
package is installed.
Procedure
To list all currently loaded kernel modules, execute:
$ lsmod Module Size Used by fuse 126976 3 uinput 20480 1 xt_CHECKSUM 16384 1 ipt_MASQUERADE 16384 1 xt_conntrack 16384 1 ipt_REJECT 16384 1 nft_counter 16384 16 nf_nat_tftp 16384 0 nf_conntrack_tftp 16384 1 nf_nat_tftp tun 49152 1 bridge 192512 0 stp 16384 1 bridge llc 16384 2 bridge,stp nf_tables_set 32768 5 nft_fib_inet 16384 1 …
In the example above:
- The first column provides the names of currently loaded modules.
- The second column displays the amount of memory per module in kilobytes.
- The last column shows the number, and optionally the names of modules that are dependent on a particular module.
Additional resources
-
/usr/share/doc/kmod/README
file -
lsmod(8)
manual page
3.4. Setting a kernel as default
The following procedure describes how to set a specific kernel as default using the grubby
command-line tool and GRUB2.
Procedure
Setting the kernel as default, using the
grubby
toolExecute the following command to set the kernel as default using the
grubby
tool:# grubby --set-default $kernel_path
The command uses a machine ID without the
.conf
suffix as an argument.NoteThe machine ID is located in the
/boot/loader/entries/
directory.
Setting the kernel as default, using the
id
argumentList the boot entries using the
id
argument and then set an intended kernel as default:# grubby --info ALL | grep id # grubby --set-default /boot/vmlinuz-<version>.<architecture>
NoteTo list the boot entries using the
title
argument, execute the# grubby --info=ALL | grep title
command.
Setting the default kernel for only the next boot
Execute the following command to set the default kernel for only the next reboot using the
grub2-reboot
command:# grub2-reboot <index|title|id>
WarningSet the default kernel for only the next boot with care. Installing new kernel RPM’s, self-built kernels, and manually adding the entries to the
/boot/loader/entries/
directory may change the index values.
3.5. Displaying information about kernel modules
When working with a kernel module, you may want to see further information about that module. This procedure describes how to display extra information about kernel modules.
Prerequisites
-
The
kmod
package is installed.
Procedure
- To display information about any kernel module, execute:
$ modinfo <KERNEL_MODULE_NAME> For example: $ modinfo virtio_net filename: /lib/modules/5.14.0-1.el9.x86_64/kernel/drivers/net/virtio_net.ko.xz license: GPL description: Virtio network driver rhelversion: 9.0 srcversion: 8809CDDBE7202A1B00B9F1C alias: virtio:d00000001v* depends: net_failover retpoline: Y intree: Y name: virtio_net vermagic: 5.14.0-1.el9.x86_64 SMP mod_unload modversions … parm: napi_weight:int parm: csum:bool parm: gso:bool parm: napi_tx:bool
+ The modinfo
command displays some detailed information about the specified kernel module. You can query information about all available modules, regardless of whether they are loaded or not. The parm
entries show parameters the user is able to set for the module, and what type of value they expect.
+
When entering the name of a kernel module, do not append the .ko.xz
extension to the end of the name. Kernel module names do not have extensions; their corresponding files do.
Additional resources
-
modinfo(8)
manual page
3.6. Loading kernel modules at system runtime
The optimal way to expand the functionality of the Linux kernel is by loading kernel modules. The following procedure describes how to use the modprobe
command to find and load a kernel module into the currently running kernel.
Prerequisites
- Root permissions
-
The
kmod
package is installed. - The respective kernel module is not loaded. To ensure this is the case, list the loaded kernel modules.
Procedure
Select a kernel module you want to load.
The modules are located in the
/lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/
directory.Load the relevant kernel module:
# modprobe <MODULE_NAME>
NoteWhen entering the name of a kernel module, do not append the
.ko.xz
extension to the end of the name. Kernel module names do not have extensions; their corresponding files do.Optionally, verify the relevant module was loaded:
$ lsmod | grep <MODULE_NAME>
If the module was loaded correctly, this command displays the relevant kernel module. For example:
$ lsmod | grep serio_raw serio_raw 16384 0
The changes described in this procedure will not persist after rebooting the system. For information on how to load kernel modules to persist across system reboots, see Loading kernel modules automatically at system boot time.
Additional resources
-
modprobe(8)
manual page
3.7. Unloading kernel modules at system runtime
At times, you find that you need to unload certain kernel modules from the running kernel. The following procedure describes how to use the modprobe
command to find and unload a kernel module at system runtime from the currently loaded kernel.
Prerequisites
- Root permissions
-
The
kmod
package is installed.
Procedure
Execute the
lsmod
command and select a kernel module you want to unload.If a kernel module has dependencies, unload those prior to unloading the kernel module. For details on identifying modules with dependencies, see Listing currently loaded kernel modules and Kernel module dependencies.
Unload the relevant kernel module:
# modprobe -r <MODULE_NAME>
When entering the name of a kernel module, do not append the
.ko.xz
extension to the end of the name. Kernel module names do not have extensions; their corresponding files do.WarningDo not unload kernel modules when they are used by the running system. Doing so can lead to an unstable or non-operational system.
Optionally, verify the relevant module was unloaded:
$ lsmod | grep <MODULE_NAME>
If the module was unloaded successfully, this command does not display any output.
After finishing this procedure, the kernel modules that are defined to be automatically loaded on boot, will not stay unloaded after rebooting the system. For information on how to counter this outcome, see Preventing kernel modules from being automatically loaded at system boot time.
Additional resources
-
modprobe(8)
manual page
3.8. Unloading kernel modules at early stages of the boot process
In certain situations it is necessary to unload a kernel module very early in the booting process. For example, when the kernel module contains a code, which causes the system to become unresponsive, and the user is not able to reach the stage to permanently disable the rogue kernel module. In that case it is possible to temporarily block the loading of the kernel module using a bootloader.
The changes described in this procedure will not persist after the next reboot. For information on how to add a kernel module to a denylist so that it will not be automatically loaded during the boot process, see Preventing kernel modules from being automatically loaded at system boot time.
Prerequisites
- You have a loadable kernel module, which you want to prevent from loading for some reason.
Procedure
Edit the relevant bootloader entry to unload the desired kernel module before the booting sequence continues.
- Use the cursor keys to highlight the relevant bootloader entry.
Press e key to edit the entry.
Figure 3.1. Kernel boot menu
- Use the cursor keys to navigate to the line that starts with linux.
Append
modprobe.blacklist=module_name
to the end of the line.Figure 3.2. Kernel boot entry
The
serio_raw
kernel module illustrates a rogue module to be unloaded early in the boot process.- Press CTRL+x keys to boot using the modified configuration.
Verification
Once the system fully boots, verify that the relevant kernel module is not loaded.
# lsmod | grep serio_raw
Additional resources
3.9. Loading kernel modules automatically at system boot time
The following procedure describes how to configure a kernel module so that it is loaded automatically during the boot process.
Prerequisites
- Root permissions
-
The
kmod
package is installed.
Procedure
Select a kernel module you want to load during the boot process.
The modules are located in the
/lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/
directory.Create a configuration file for the module:
# echo <MODULE_NAME> > /etc/modules-load.d/<MODULE_NAME>.conf
NoteWhen entering the name of a kernel module, do not append the
.ko.xz
extension to the end of the name. Kernel module names do not have extensions; their corresponding files do.Optionally, after reboot, verify the relevant module was loaded:
$ lsmod | grep <MODULE_NAME>
The example command above should succeed and display the relevant kernel module.
The changes described in this procedure will persist after rebooting the system.
Additional resources
-
modules-load.d(5)
manual page
3.10. Preventing kernel modules from being automatically loaded at system boot time
The following procedure describes how to add a kernel module to a denylist so that it will not be automatically loaded during the boot process.
Prerequisites
- Root permissions
-
The
kmod
package is installed. - Ensure that a kernel module in a denylist is not vital for your current system configuration.
Procedure
Select a kernel module that you want to put in a denylist:
$ lsmod Module Size Used by fuse 126976 3 xt_CHECKSUM 16384 1 ipt_MASQUERADE 16384 1 uinput 20480 1 xt_conntrack 16384 1 …
The
lsmod
command displays a list of modules loaded to the currently running kernel.Alternatively, identify an unloaded kernel module you want to prevent from potentially loading.
All kernel modules are located in the
/lib/modules/<KERNEL_VERSION>/kernel/<SUBSYSTEM>/
directory.
Create a configuration file for a denylist:
# vim /etc/modprobe.d/blacklist.conf # Blacklists <KERNEL_MODULE_1> blacklist <MODULE_NAME_1> install <MODULE_NAME_1> /bin/false # Blacklists <KERNEL_MODULE_2> blacklist <MODULE_NAME_2> install <MODULE_NAME_2> /bin/false # Blacklists <KERNEL_MODULE_n> blacklist <MODULE_NAME_n> install <MODULE_NAME_n> /bin/false …
The example shows the contents of the
blacklist.conf
file, edited by thevim
editor. Theblacklist
line ensures that the relevant kernel module will not be automatically loaded during the boot process. Theblacklist
command, however, does not prevent the module from being loaded as a dependency for another kernel module that is not in a denylist. Therefore theinstall
line causes the/bin/false
to run instead of installing a module.The lines starting with a hash sign are comments to make the file more readable.
NoteWhen entering the name of a kernel module, do not append the
.ko.xz
extension to the end of the name. Kernel module names do not have extensions; their corresponding files do.Create a backup copy of the current initial ramdisk image before rebuilding:
# cp /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).bak.$(date +%m-%d-%H%M%S).img
The command above creates a backup
initramfs
image in case the new version has an unexpected problem.Alternatively, create a backup copy of other initial ramdisk image which corresponds to the kernel version for which you want to put kernel modules in a denylist:
# cp /boot/initramfs-<SOME_VERSION>.img /boot/initramfs-<SOME_VERSION>.img.bak.$(date +%m-%d-%H%M%S)
Generate a new initial ramdisk image to reflect the changes:
# dracut -f -v
If you are building an initial ramdisk image for a different kernel version than you are currently booted into, specify both target
initramfs
and kernel version:# dracut -f -v /boot/initramfs-<TARGET_VERSION>.img <CORRESPONDING_TARGET_KERNEL_VERSION>
Reboot the system:
$ reboot
The changes described in this procedure will take effect and persist after rebooting the system. If you improperly put a key kernel module in a denylist, you can face an unstable or non-operational system.
Additional resources
- How do I prevent a kernel module from loading automatically?
-
dracut(8)
manual page
3.11. Compiling custom kernel modules
You can build a sampling kernel module as requested by various configurations at hardware and software level.
Prerequisites
-
You installed the
kernel-devel
,gcc
, andelfutils-libelf-devel
packages. - You have root permissions.
-
You created the
/root/testmodule/
directory where you compile the custom kernel module.
Procedure
Create the
/root/testmodule/test.c
file with the following content:#include <linux/module.h> #include <linux/kernel.h> int init_module(void) { printk("Hello World\n This is a test\n"); return 0; } void cleanup_module(void) { printk("Good Bye World"); }
The
test.c
file is a source file that provides the main functionality to the kernel module. The file has been created in a dedicated/root/testmodule/
directory for organizational purposes. After the module compilation, the/root/testmodule/
directory will contain multiple files.The
test.c
file includes from the system libraries:-
The
linux/kernel.h
header file is necessary for theprintk()
function in the example code. The
linux/module.h
file contains function declarations and macro definitions to be shared between several source files written in C programming language.Next follow the
init_module()
andcleanup_module()
functions to start and end the kernel logging functionprintk()
, which prints text.
-
The
Create the
/root/testmodule/Makefile
file with the following content:obj-m := test.o
The Makefile contains instructions that the compiler has to produce an object file specifically named
test.o
. Theobj-m
directive specifies that the resultingtest.ko
file is going to be compiled as a loadable kernel module. Alternatively, theobj-y
directive would instruct to buildtest.ko
as a built-in kernel module.- Compile the kernel module:
# make -C /lib/modules/$(uname -r)/build M=/root/testmodule modules
make: Entering directory '/usr/src/kernels/5.14.0-1.3.1.el9.x86_64'
CC [M] /root/testmodule/test.o
MODPOST /root/testmodule/Module.symvers
ERROR: modpost: missing MODULE_LICENSE() in /root/testmodule/test.o
make[1]: * [scripts/Makefile.modpost:150: /root/testmodule/Module.symvers] Error 1
make[1]: * Deleting file '/root/testmodule/Module.symvers'
make: * [Makefile:1776: modules] Error 2
make: Leaving directory '/usr/src/kernels/5.14.0-1.3.1.el9.x86_64'
+ The compiler creates an object file (test.o
) for each source file (test.c
) as an intermediate step before linking them together into the final kernel module (test.ko
).
+ After a successful compilation, /root/testmodule/
contains additional files that relate to the compiled custom kernel module. The compiled module itself is represented by the test.ko
file.
Verification
Optional: check the contents of the
/root/testmodule/
directory:ls -l /root/testmodule/ total 452 -rw-r—r--. 1 root root 16 Jul 12 10:16 Makefile -rw-r—r--. 1 root root 32 Jul 12 10:16 modules.order -rw-r—r--. 1 root root 0 Jul 12 10:16 Module.symvers -rw-r—r--. 1 root root 197 Jul 12 10:15 test.c -rw-r—r--. 1 root root 219736 Jul 12 10:16 test.ko -rw-r—r--. 1 root root 826 Jul 12 10:16 test.mod.c -rw-r—r--. 1 root root 113760 Jul 12 10:16 test.mod.o -rw-r—r--. 1 root root 107424 Jul 12 10:16 test.o
Copy the kernel module to the
/lib/modules/$(uname -r)/
directory:# cp /root/testmodule/test.ko /lib/modules/$(uname -r)/
Update the modular dependency list:
# depmod -a
- Load the kernel module:
# modprobe -v test insmod /lib/modules/5.14.0-1.el9.x86_64/test.ko
Verify that the kernel module was successfully loaded:
# lsmod | grep test test 16384 0
Read the latest messages from the kernel ring buffer:
# dmesg … [74422.545004] Hello World This is a test
Additional resources