Kernel modules are pieces of code that can be loaded and unloaded into the kernel upon demand. They extend the functionality of the kernel without the need to reboot the system.
To create a kernel module, you can read The Linux Kernel Module Programming Guide. A module can be configured as built-in or loadable. To dynamically load or remove a module, it has to be configured as a loadable module in the kernel configuration (the line related to the module will therefore display the letter
- 1 Obtaining information
- 2 Automatic module handling
- 3 Manual module handling
- 4 Setting module options
- 5 Aliasing
- 6 Blacklisting
- 7 Troubleshooting
- 8 See also
Modules are stored in
/usr/lib/modules/kernel_release. You can use the command
uname -r to get your current kernel release version.
To show what kernel modules are currently loaded:
To show information about a module:
$ modinfo module_name
To list the options that are set for a loaded module:
$ systool -v -m module_name
To display the comprehensive configuration of all the modules:
$ modprobe -c | less
To display the configuration of a particular module:
$ modprobe -c | grep module_name
List the dependencies of a module (or alias), including the module itself:
$ modprobe --show-depends module_name
Automatic module handling
Today, all necessary modules loading is handled automatically by udev, so if you do not need to use any out-of-tree kernel modules, there is no need to put modules that should be loaded at boot in any configuration file. However, there are cases where you might want to load an extra module during the boot process, or blacklist another one for your computer to function properly.
Kernel modules can be explicitly loaded during boot and are configured as a static list in files under
/etc/modules-load.d/. Each configuration file is named in the style of
/etc/modules-load.d/<program>.conf. Configuration files simply contain a list of kernel modules names to load, separated by newlines. Empty lines and lines whose first non-whitespace character is
; are ignored.
# Load virtio-net.ko at boot virtio-net
Seefor more details.
Manual module handling
Kernel modules are handled by tools provided bypackage. You can use these tools manually.
To load a module:
# modprobe module_name
To load a module by filename (i.e. one that is not installed in
# insmod filename [args]
To unload a module:
# modprobe -r module_name
# rmmod module_name
Setting module options
To pass a parameter to a kernel module, you can pass them manually with modprobe or assure certain parameters are always applied using a modprobe configuration file or by using the kernel command line.
Manually at load time using modprobe
The basic way to pass parameters to a module is using the modprobe command. Parameters are specified on command line using simple
# modprobe module_name parameter_name=parameter_value
Using files in /etc/modprobe.d/
/etc/modprobe.d/ directory can be used to pass module settings to udev, which will use
modprobe to manage the loading of the modules during system boot. Configuration files in this directory can have any name, given that they end with the
.conf extension. The syntax is:
options module_name parameter_name=parameter_value
# On ThinkPads, this lets the 'thinkfan' daemon control fan speed options thinkpad_acpi fan_control=1
Using kernel command line
If the module is built into the kernel, you can also pass options to the module using the kernel command line. For all common bootloaders, the following syntax is correct:
Simply add this to your bootloader's kernel-line, as described in Kernel Parameters.
Aliases are alternate names for a module. For example:
alias my-mod really_long_modulename means you can use
modprobe my-mod instead of
modprobe really_long_modulename. You can also use shell-style wildcards, so
alias my-mod* really_long_modulename means that
modprobe my-mod-something has the same effect. Create an alias:
alias mymod really_long_module_name
Some modules have aliases which are used to automatically load them when they are needed by an application. Disabling these aliases can prevent automatic loading but will still allow the modules to be manually loaded.
# Prevent Bluetooth autoload alias net-pf-31 off
Blacklisting, in the context of kernel modules, is a mechanism to prevent the kernel module from loading. This could be useful if, for example, the associated hardware is not needed, or if loading that module causes problems: for instance there may be two kernel modules that try to control the same piece of hardware, and loading them together would result in a conflict.
Some modules are loaded as part of the initramfs.
mkinitcpio -M will print out all automatically detected modules: to prevent the initramfs from loading some of those modules, blacklist them in
mkinitcpio -v will list all modules pulled in by the various hooks (e.g.
block hook, etc.). Remember to add that
.conf file to the
FILES section in
/etc/mkinitcpio.conf, if you have not done so already, and rebuild the initramfs once you have blacklisted the modules, and reboot afterwards.
Using files in /etc/modprobe.d/
.conf file inside
/etc/modprobe.d/ and append a line for each module you want to blacklist, using the
blacklist keyword. If for example you want to prevent the
pcspkr module from loading:
# Do not load the 'pcspkr' module on boot. blacklist pcspkr
Using kernel command line
You can also blacklist modules from the bootloader.
modprobe.blacklist=modname1,modname2,modname3 to your bootloader's kernel line, as described in Kernel parameters.
Modules do not load
In case a specific module does not load and the boot log (accessible with
journalctl -b) says that the module is blacklisted, but the directory
/etc/modprobe.d/ does not show a corresponding entry, check another modprobe source folder at
/usr/lib/modprobe.d/ for blacklisting entries.
A module will not be loaded if the "vermagic" string contained within the kernel module does not match the value of the currently running kernel. If it is known that the module is compatible with the current running kernel the "vermagic" check can be ignored with