Priming the kernel

The Linux kernel is a program that constitutes the central core of the operating system. It can directly access the underlying hardware and make it available to the user to work with it using the shell.

In this recipe, we will learn how to prime the kernel by working with dynamically loaded kernel modules. Kernel modules are device driver files (or filesystem driver files) that add support for specific pieces of hardware so that we can access them.

You will not work very often with kernel modules as a system administrator, but having a basic understanding of them can be beneficial if you have a device driver problem or an unsupported piece of hardware.

Getting ready

To complete this recipe, you will require a minimal installation of the CentOS 7 operating system with root privileges.

How to do it...

1. To begin, log in to your system using your root user account, and type the following command in order to show the status of all Linux kernel modules currently loaded:

   lsmod
   

2. In the output, you will see all loaded device drivers (module); let's see if a cdrom and floppy module have been loaded:

   lsmod | grep "cdrom\|floppy"
   

3. On most servers, there will be the following output:

   cdrom 42556 1 sr_mod
   floppy 69417 0
   

4. Now, we want to show detailed information about the sr_mod cdrom module:

   modinfo sr_mod
   

5. Next, unload these two modules from the kernel (you can only do this if the module and hardware have been found and loaded on your system; otherwise skip this step):

   modprobe -r -v sr_mod floppy
   

6. Check if the modules have been unloaded (output should be empty now):

   lsmod | grep "cdrom\|floppy"
   

7. Now, to show a list of all kernel modules available on your system, use the following directory where you can look around:

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

8. Let's pick a module from the subfolder /lib/modules/$(uname -r)/kernel/drivers/ called bluetooth and verify that it is not loaded yet (output should be empty):

   lsmod | grep btusb
   

9. Get more information about the module:

   modinfo btusb
   

10. Finally, load this bluetooth USB module:

    modprobe btusb
    

11. Verify again that it is loaded now:

    lsmod | grep "btusb"
    

How it works...

Kernel modules are the drivers that your system's hardware needs to communicate with the kernel and operating system (also, they are needed to load and enable filesystems). They are loaded dynamically, which means that only the drivers or modules are loaded at runtime, which reflects your own custom specific hardware.

So, what did we learn from this experience?

We started using the lsmod command to view all the currently loaded kernel modules in our system. The output shows three columns: the module name, the amount of RAM the module occupies while loaded, and the number of processes this module is used by and a list of dependencies of other modules using it. Next, we checked if the cdrom and floppy modules have been loaded by the kernel yet. In the output, we saw that the cdrom module is dependent on the sr_mod module. So, next we used the modinfo command to get detailed information about it. Here, we learned that sr_mod is the SCSI cdrom driver.

Since we only need the floppy and cdrom drivers while we first installed the base system we can now disable those kernel modules and save us some memory. We unloaded the modules and their dependencies with the modprobe -r command and rechecked whether this was successful by using lsmod again.

Next, we browsed the standard kernel module directory (for example, /lib/modules/$(uname -r)/kernel/drivers). The uname substring command prints out the current kernel version so that it makes sure that we are always listing the current kernel modules after having installed more than one version of the kernel on our system.

This kernel module directory keeps all the available modules on your system structured and categorized using subdirectories. We navigated to drivers/bluetooth and picked the btusb module. Doing modinfo on the btusb module, we found out that it is the generic bluetooth USB driver. Finally, we decided that we needed this module, so we loaded it using the modprobe command again.

There's more...

It's important to say that loading and unloading kernel modules using the modprobe command is not persistent; this means that if you restart the system, all your changes to kernel modules will be gone. To load a kernel module at boot time create a new executable script file, /etc/sysconfig/modules/<filename>.modules, where <filename> is a name of your choice. There you put in modprobe execution commands just as you would on the normal command line. Here is an example of additionally loading the bluetooth driver on startup, for example /etc/sysconfig/modules/btusb.modules:

#!/bin/sh
if [ ! -c /dev/input/uinput ] ; then
exec /sbin/modprobe btusb >/dev/null 2>&1
fi

Finally, you need to make your new module file executable via the following line:

chmod +x /etc/sysconfig/modules/btusb.modules

Recheck your new module settings with lsmod after reboot.

To remove a kernel module at boot time for example sr_mod, we need to blacklist the module's name using the rdblacklist kernel boot option. We can set this option by appending it to the end of the GRUB_CMDLINE_LINUX directive in the GRUB2 configuration file /etc/default/grub so it will look like:

GRUB_CMDLINE_LINUX="rd.lvm.lv=centos/root rd.lvm.lv=centos/swap crashkernel=auto rhgb quiet rdblacklist=sr_mod"

If you need to blacklist multiple modules, the rdblacklist option can be specified multiple times like rdblacklist=sr_mod rdblacklist=nouveau.

Next recreate the GRUB2 configuration using the grub2-mkconfig command (to learn more read the Getting started and customizing the boot loader recipe in Chapter 1, Installing CentOS).

grub2-mkconfig -o /boot/grub2/grub.cfg

Finally we also need to blacklist the module name using the blacklist directive in a new.conf file of your choice in the /etc/modprobe.d/ directory for example:

echo "blacklist sr_mod" >> /etc/modprobe.d/blacklist.conf