5 Kernel Modules
WARNING:
Oracle Linux 7 is now in Extended Support. See Oracle Linux Extended Support and Oracle Open Source Support Policies for more information.
Migrate applications and data to Oracle Linux 8 or Oracle Linux 9 as soon as possible.
This chapter describes how to load, unload, and modify the behavior of kernel modules.
About Kernel Modules
The boot loader loads the kernel into memory. You can add new code to the kernel by including the source files in the kernel source tree and recompiling the kernel. Kernel modules, which can be dynamically loaded and unloaded on demand, provide device drivers that allow the kernel to access new hardware, support different file system types, and extend its functionality in other ways. To avoid wasting memory on unused device drivers, Oracle Linux supports loadable kernel modules (LKMs), which allow a system to run with only the device drivers and kernel code that it requires loaded into memory.
Listing Information about Loaded Modules
Use the lsmod command to list the modules that are currently loaded into the kernel.
sudo lsmod
Module Size Used by nls_utf8 1405 1 fuse 59164 0 tun 12079 0 autofs4 22739 3 ... ppdev 7901 0 parport_pc 21262 0 parport 33812 2 ppdev,parport_pc ...
Note:
        This command produces its output by reading the
        /proc/modules file.
      
                     
      The output shows the module name, the amount of memory it uses,
      the number of processes using the module and the names of other
      modules on which it depends. In the sample output, the module
      parport depends on the modules
      ppdev and parport_pc, which
      are loaded in advance of parport. Two processes
      are currently using all three modules.
    
                  
To display detailed information about a module, use the modinfo command, for example:
sudo modinfo ahci
filename: /lib/modules/2.6.32-300.27.1.el6uek.x86_64/kernel/drivers/ata/ahci.ko version: 3.0 license: GPL description: AHCI SATA low-level driver author: Jeff Garzik srcversion: AC5EC885397BF332DE16389 alias: pci:v*d*sv*sd*bc01sc06i01* ... depends: vermagic: 2.6.32-300.27.1.el6uek.x86_64 SMP mod_unload modversions parm: skip_host_reset:skip global host reset (0=don't skip, 1=skip) (int) parm: ignore_sss:Ignore staggered spinup flag (0=don't ignore, 1=ignore) (int) ...
The output includes the following information:
- 
                        filename
- 
                        
                        Absolute path of the kernel object file. 
- 
                        version
- 
                        
                        Version number of the module. 
- 
                        description
- 
                        
                        Short description of the module. 
- 
                        srcversion
- 
                        
                        Hash of the source code used to create the module. 
- 
                        alias
- 
                        
                        Internal alias names for the module. 
- 
                        depends
- 
                        
                        Comma-separated list of any modules on which this module depends. 
- 
                        vermagic
- 
                        
                        Kernel version that was used to compile the module, which is checked against the current kernel when the module is loaded. 
- 
                        parm
- 
                        
                        Module parameters and descriptions. 
      Modules are loaded into the kernel from kernel object
      (ko) files in the
      /lib/modules/kernel_version/kernel
      directory. To display the absolute path of a kernel object file,
      specify the -n option, for example:
    
                  
sudo modinfo -n parport
/lib/modules/2.6.32-300.27.1.el6uek.x86_64/kernel/drivers/parport/parport.ko
      For more information, see the lsmod(5) and
      modinfo(8) manual pages.
    
                  
Loading and Unloading Modules
The modprobe command loads kernel modules, for example:
sudo modprobe nfs sudo lsmod | grep nfs
nfs 266415 0 lockd 66530 1 nfs fscache 41704 1 nfs nfs_acl 2477 1 nfs auth_rpcgss 38976 1 nfs sunrpc 204268 5 nfs,lockd,nfs_acl,auth_rpcgss
Use the -v verbose option to show if any additional modules are loaded to resolve dependencies.
sudo modprobe -v nfs
insmod /lib/modules/2.6.32-300.27.1.el6uek.x86_64/kernel/net/sunrpc/auth_gss/auth_rpcgss.ko insmod /lib/modules/2.6.32-300.27.1.el6uek.x86_64/kernel/fs/nfs_common/nfs_acl.ko insmod /lib/modules/2.6.32-300.27.1.el6uek.x86_64/kernel/fs/fscache/fscache.ko ...
      To determine the dependencies, the modprobe
      command queries the
      /lib/modules/kernel_version/modules.dep
      file, which the depmod utility creates when you
      install kernel modules.
    
                  
Note:
modprobe does not reload modules that are already loaded. You must first unload a module before you can load it again.
Use the -r option to unload kernel modules, for example:
sudo modprobe -rv nfs
rmmod /lib/modules/2.6.32-300.27.1.el6uek.x86_64/kernel/fs/nfs/nfs.ko rmmod /lib/modules/2.6.32-300.27.1.el6uek.x86_64/kernel/fs/lockd/lockd.ko rmmod /lib/modules/2.6.32-300.27.1.el6uek.x86_64/kernel/fs/fscache/fscache.ko ...
Modules are unloaded in the reverse order that they were loaded. Modules are not unloaded if a process or another loaded module requires them.
Note:
modprobe uses the insmod and rmmod utilities to load and unload modules. As insmod and rmmod do not resolve module dependencies, do not use these utilities.
      For more information, see the modprobe(8) and
      modules.dep(5) manual pages.
    
                  
About Module Parameters
Modules accept parameters that you can specify using modprobe to modify a module's behavior:
sudo modprobe module_name parameter=value ...
Use spaces to separate multiple parameter/value pairs. Array values are represented by a comma-separated list, for example:
sudo modprobe foo arrayparm=1,2,3,4
      You can also change the values of some parameters for loaded
      modules and built-in drivers by writing the new value to a file
      under
      /sys/module/module_name/parameters,
      for example:
    
                  
echo 0 > /sys/module/ahci/parameters/skip_host_reset
      The /etc/modprobe.d directory contains
      .conf configuration files specify module
      options, create module aliases, and override the usual behavior of
      modprobe for modules with special requirements.
      The /etc/modprobe.conf file that was used with
      earlier versions of modprobe is also valid if
      it exists. Entries in the /etc/modprobe.conf
      and /etc/modprobe.d/*.conf files use the same
      syntax.
    
                  
The following are commonly used commands in modprobe configuration files:
- 
                        alias
- 
                        
                        Creates an alternate name for a module. The alias can include shell wildcards. For example, create an alias for the sd-modmodule:alias block-major-8-* sd_mod As a result, a command such as modprobe block-major-8-0 has the same effect as modprobe sd_mod. 
- 
                        blacklist
- 
                        
                        Ignore a module's internal alias that is displayed by the modinfo command. This command is typically used if the associated hardware is not required, if two or more modules both support the same devices, or if a module invalidly claims to support a device. For example, to blocklist the alias for the frame-buffer driver cirrusfb:blacklist cirrusfb The /etc/modprobe.d/blacklist.conffile prevents hotplug scripts from loading a module, usually so that a different driver binds the module instead, regardless of which driver happens to be probed first.
- 
                        install
- 
                        
                        Runs a shell command instead of loading a module into the kernel. For example, load the module snd-emu10k1-synthinstead ofsnd-emu10k1:install snd-emu10k1 /sbin/modprobe --ignore-install snd-emu10k1 && \ /sbin/modprobe snd-emu10k1-synth 
- 
                        options
- 
                        
                        Defines options for a module,. For example, define the nohwcryptandqosoptions for theb43module:options b43 nohwcrypt=1 qos=0 
- 
                        remove
- 
                        
                        Runs a shell command instead of unloading a module. For example, unmount /proc/fs/nfsdbefore unloading thenfsdmodule:remove nfsd { /bin/umount /proc/fs/nfsd > /dev/null 2>&1 || :; } ; \ /sbin/modprobe -r --first-time --ignore-remove nfsdFor more information, see the modprobe.conf(5)manual page.
Specifying Modules To Be Loaded at Boot Time
The system loads most modules automatically at boot time. If necessary, you can specify an additional module that should be loaded.
To specify a module to be loaded at boot time:
- 
                        
                        Create a file in the /etc/sysconfig/modulesdirectory. The file name must have the extension.modules, for examplefoo.modules.
- 
                        
                        Edit the file to create the script that loads the module. The script to load a module can be a simple modprobe call, for example: #!/bin/sh modprobe foo or more complex to include error handling: #!/bin/sh if [ ! -c /dev/foo ] ; then exec /sbin/modprobe foo > /dev/null 2>&1 fi 
- 
                        
                        Use the following command to make the script executable: sudo chmod 755 /etc/sysconfig/modules/foo.modules 
About Weak Update Modules
      External modules, such as drivers installed using a driver update
      disk, are usually installed into
      /lib/modules/kernel-version/extra.
      Modules stored in this directory are given preference over
      matching modules included with the kernel, itself, when you
      attempt to load them. This means that external drivers and modules
      can be installed to override kernel modules where hardware issues
      may need resolution. For each subsequent kernel update, it is
      important that the external module is made available to each
      compatible kernel to avoid potential boot issues resulting from
      driver incompatibilities with the affected hardware.
    
                  
      Since the requirement to load the external module with each
      compatible kernel update is system critical, a mechanism is in
      place so that external modules can be loaded as weak update
      modules for compatible kernels. Weak update modules are made
      available by creating symbolic links to compatible modules in the
      /lib/modules/kernel-version/weak-updates
      directory. The package manager handles this process automatically
      when it detects driver modules installed in any
      /lib/modules/kernel-version/extra
      directories for compatible kernels. For example, installation of
      the kmod-megaraid_sas-uek driver update package
      on the Driver Update Disk (DUD) for the Oracle Linux 7.4 might install the
      following:
    
                  
/lib/modules/4.1.12-61.1.18.el7uek.x86_64/extra/megaraid_sas /lib/modules/4.1.12-61.1.18.el7uek.x86_64/extra/megaraid_sas/megaraid_sas.ko
      The new driver module is installed into the
      extra directory for the
      4.1.12-61.1.18.el7uek.x86_64, which was the
      kernel version that was originally used to build the module.
    
                  
      A subsequent kernel update means that the system is now running
      the 4.1.12-112.14.13.el7uek.x86_64 version of
      the kernel. This kernel is compatible with the module installed
      for the previous kernel, so the external module is automatically
      added, as a symbolic link, in the weak-updates
      directory as part of the installation process:
    
                  
ls -l /lib/modules/4.1.12-112.14.13.el7uek.x86_64/weak-updates/megaraid_sas/*.ko
lrwxrwxrwx. 1 root root 76 Jan 30 04:52 /lib/modules/4.1.12-112.14.13.el7uek.x86_64\
    /weak-updates/megaraid_sas/megaraid_sas.ko \
     -> /lib/modules/4.1.12-61.1.18.el7uek.x86_64/extra/megaraid_sas/megaraid_sas.koThe output means that the external module is loaded for subsequent kernel updates.
In most cases, weak updates make sense and ensure that no extra work must be done to carry an external module through subsequent kernel updates. This prevents possible driver related boot issues after kernel upgrades and maintains the predictable running of a system and its hardware.
In some cases you may wish to remove weak update modules for a newer kernel. For instance, if an issue has been resolved for a driver that is shipped in the newer kernel and you would prefer to use this driver over the external module that you installed as part of a driver update.
You can remove weak update modules by removing the symbolic links for each kernel, manually. For example:
sudo rm -rf /lib/modules/4.1.12-112.14.13.el7uek.x86_64/weak-updates/megaraid_sas/
For more information about external driver modules and driver update disks, see Oracle Linux 7: Installation Guide.