Check modules loaded linux

Kernel module

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 M ).

To rebuild a kernel module automatically when a new kernel is installed, see Dynamic Kernel Module Support (DKMS).

Obtaining information

Modules are stored in /usr/lib/modules/kernel_release . You can use the command uname -r to get your current kernel release version.

Note: Module names often use underscores ( _ ) or dashes ( — ); however, those symbols are interchangeable when using the modprobe command and in configuration files in /etc/modprobe.d/ .

To show what kernel modules are currently loaded:

To show information about a module:

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:

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 loading

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.

systemd

Kernel modules can be explicitly listed in files under /etc/modules-load.d/ for systemd to load them during boot. 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 # or ; are ignored.

/etc/modules-load.d/virtio-net.conf

# Load virtio_net.ko at boot virtio_net

Early module loading

The initramfs image may not contain the kernel modules asked for in /etc/modules-load.d/ , it also may lack the files that have been set in that folder. Early module loading depend on the initramfs generator used:

Manual module handling

Kernel modules are handled by tools provided by kmod package. You can use these tools manually.

Note: If you have upgraded your kernel but have not yet rebooted, modprobe will fail with no error message and exit with code 1, because the path /usr/lib/modules/$(uname -r)/ no longer exists. Check manually if this path exists when modprobe failed to determine if this is the case.

# modprobe module_name 

To load a module by filename (i.e. one that is not installed in /usr/lib/modules/$(uname -r)/ ):

# modprobe -r 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. If the module is built into the kernel, the kernel command line must be used and other methods will not work.

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 key=value assignments:

# modprobe module_name parameter_name=parameter_value 

Using files in /etc/modprobe.d/

Files in /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:

/etc/modprobe.d/myfilename.conf

options module_name parameter_name=parameter_value

Multiple module parameters are separated by spaces, in turn a parameter can receive a list of values which is separated by commas:

/etc/modprobe.d/myfilename.conf

options module_name param1=value1 param2=value2a,value2b …

# On ThinkPads, this lets the 'thinkfan' daemon control fan speed options thinkpad_acpi fan_control=1

Note: If any of the affected modules is loaded from the initramfs, then you will need to add the appropriate .conf file to FILES in mkinitcpio.conf or use the modconf hook, then regenerate the initramfs to include the .conf file. To see the contents of the default initramfs use lsinitcpio.

Using kernel command line

You can also pass options to the module using the kernel command line. This is the only working option for modules built into the kernel. For all common boot loaders, the following syntax is correct:

module_name.parameter_name=parameter_value 

thinkpad_acpi.fan_control=1

Simply add this to your bootloader’s kernel-line, as described in Kernel Parameters.

Aliasing

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

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 a .conf file under /etc/modprobe.d and it shall be added in by the modconf hook during image generation. Running mkinitcpio -v will list all modules pulled in by the various hooks (e.g. filesystems hook, block hook, etc.). Remember to add that .conf file to the FILES array in /etc/mkinitcpio.conf if you do not have the modconf hook in your HOOKS array (e.g. you have deviated from the default configuration), and once you have blacklisted the modules regenerate the initramfs, and reboot afterwards.

Using files in /etc/modprobe.d/

Create a .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 to avoid sounds through the PC speaker:

# Do not load the 'pcspkr' module on boot. blacklist pcspkr

Note: The blacklist command will blacklist a module so that it will not be loaded automatically, but the module may be loaded if another non-blacklisted module depends on it or if it is loaded manually.

However, there is a workaround for this behaviour; the install command instructs modprobe to run a custom command instead of inserting the module in the kernel as normal, so you can force the module to always fail loading with:

/etc/modprobe.d/blacklist.conf

. install module_name /bin/true .

This will effectively blacklist that module and any other that depends on it.

Using kernel command line

Tip: This can be very useful if a broken module makes it impossible to boot your system.

You can also blacklist modules from the bootloader.

Simply add module_blacklist=modname1,modname2,modname3 to your bootloader’s kernel line, as described in Kernel parameters.

Note: When you are blacklisting more than one module, note that they are separated by commas only. Spaces or anything else might presumably break the syntax.

Troubleshooting

Modules do not load

In case a specific module does not load and the boot log (accessible by running journalctl -b as root) says that the module is blacklisted, but the directory /etc/modprobe.d/ does not show a corresponding entry, check another modprobe source directory 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 modprobe —force-vermagic .

Warning: Ignoring the version checks for a kernel module can cause a kernel to crash or a system to exhibit undefined behavior due to incompatibility. Use —force-vermagic only with the utmost caution.

See also

Источник

How to list all loadable kernel modules?

I’m looking for a few kernel modules to load i2c-dev and i2c-bcm2708 . But the modprobe command returns:

sudo modprobe i2c-dev modprobe: module i2c-dev not found in modules.dep 

The kernel didnt compile this i2c-dev. You didnt find this module.The kernel modules located /lib/modules/’kernel-version’/drivers. When you are looking for linux drivers.

You can check on /boot/config-‘kernel-version’ and read this config file.You should know which linux modules are loaded or modulars or during compiling kernel didnt enable i2c-dev module.

5 Answers 5

• By default modprobe loads modules from kernel subdirectories located in the /lib/modules/$(uname -r) directory. Usually all files have extension .ko , so you can list them with

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

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

Redhat 7 modules files are compressed in .xz (not sure if it is because of kernel version or OS version.. if someone can clarify it to me?) so I think you might not find them with jimmij’s find command. Use instead find /lib/modules/$(uname -r) -type f -name *.ko*

@posinux: beware : the shell may expand your *.ko* if you happen to have in your current dir some file matching it. better to escape it between single quotes: find /lib/modules/$(uname -r) -type f -name ‘*.ko*’

Type modprobe and press tab, the autocomplete list should contain all the loadable modules

Also its double tab, and you may get prompted that there is a specific large number of entries to list, then press y to list them. Also this answer does not provide the second part to OP’s question which directory are they located?

takes very long even on newer systems and doesn’t give a really good way to look at ll the entries. just paging into one direction of 30k possibilities is probably not very much enlightening

There is lsmod command of kmod package in Arch Linux what lists and shows the status of Linux kernel modules that contains other useful commands such as modinfo , rmmod modprobe too.

To list all binaries provided by the package you can type:

pacman -Ql kmod | grep /bin/ --color=always 

, and you can also check for the owner package of a binary with pacman -Qo lsmod .

Q switch is to query locally installed packages (unlike S to synchronize, ie. to check remotely).

Where it’s important to highlight that lsmod only shows already loaded modules. The Author of this thread had the problem to load a module that wasn’t in the map of the loadable kernel modules. Besides, this solution only applies to archlinux. Which might be not the distribution of the Author and might not solve the problem for others.

@Akendo lsmod is also available on Ubuntu, at least. However, I agree this does not solve OP’s problem.

There is absolutely no point in talking about Arch specifically, and lsmod is a universally available command. Furthermore, the whole point of the question is to list loadable/available modules, whereas lsmod only prints listed modules. This answer should be moderated.

I prefer to use depmod . With the command: depmod -av|grep MOD_NAME , your system will generate the modules.dep/map files and grep through it. The -v parameter is important for verbosity and -a to ensure that all possible modules from /lib/modules/ are used for the modules.dep file.

This way it’s possible to ensure, that a requested kernel module is mapped to the kernel as loadable. When the desire kernel module is not listed in the output, you know that the kernel won’t find it.

According to man depmod option -a is not needed — it is enabled by default, if no file names are given in command line.

You can check how autocompletion does it:

$ complete -p modprobe complete -F _modprobe modprobe declare -f _modprobe _modprobe () < . 

In that function there's an internal _installed_modules

$ declare -f _installed_modules _installed_modules () < COMPREPLY=($(compgen -W "$(PATH="$PATH:/sbin" lsmod | awk '')" -- "$1")) > 

So lsmod | awk '' should show you the list of modules

Источник