The Linux kernel is the core of the operating system, but it doesn't need to know about every single piece of hardware or filesystem in the world from the moment it boots. The concept of kernel modules solves this by letting you add or remove functionality—like support for a new printer or a network filesystem—while the computer is running, without a reboot. For the LPIC-1 exam, mastering kernel modules is about understanding how to probe hardware, manage these modules, and configure devices efficiently, which is a daily task for any Linux system administrator.
Jump to a section
A simple way to picture Kernel Modules and Hardware Configuration
A 1970s apartment building with a grumpy, overworked super named Frank. Frank's building has a single, ancient central heating boiler in the basement that was originally designed to warm only the hallways. When a tenant in 3B installs a grow light for her orchids, the building's electrical panel trips. Frank can't replace the entire building's electrical system—that would cost a fortune and require shutting off power for a week.
Instead, Frank has a special toolbox. For the grow light problem, he chooses a 'heavy-duty outlet module' from his box—a ready-made component designed to handle high-wattage loads. He screws it into the existing panel, flips a dedicated breaker, and the light works without tripping anything else. Later, a tenant in 5A wants to connect a high-end audio system. Frank grabs a 'ground-loop isolator module' from the same toolbox, snaps it in, and the hum disappears. Each module slides into the building's standard, pre-existing slots. Frank's toolbox is the Linux kernel's world of loadable kernel modules. The building's electrical panel is the kernel—the core of the operating system. Each module file is a discreet, self-contained piece of functionality (a device driver, a filesystem, a network protocol) that Frank (the root user, using commands like 'insmod' or 'modprobe') can insert into the running kernel without ever shutting down the building's power. The old, built-in boiler represents the kernel's static, compiled-in functionality—changing that *would* require a full reboot. Frank's genius is in adding new hardware support (the grow light, the audio system) while the building is fully occupied and active.
At its heart, the Linux kernel is a single, monolithic piece of software. When you power on a Linux computer, the kernel is loaded into memory and it starts managing the CPU, memory, and all connected hardware. However, the kernel cannot possibly include drivers for every single device ever made—that would make it enormous, slow to load, and impossible to update without recompiling the entire kernel. This is where kernel modules come in.
A kernel module is a piece of compiled code that can be inserted into or removed from the running kernel at any time. Modules are typically stored in the /lib/modules/$(uname -r)/ directory. Each module is a file ending in '.ko' (kernel object). They are the most common way to add support for hardware (like a network card or a sound card), filesystems (like the ext4 or XFS filesystem), or other kernel features (like firewall rules or encryption).
Why is this important? Before modules existed, if you bought a new network card, you had to recompile the entire kernel to include its driver, then reboot. With modules, you just plug in the card, load the right module, and the hardware works immediately. This hot-pluggable capability is revolutionary for servers that must run 24/7.
The key commands for managing modules are:
lsmod: Lists all currently loaded modules. It shows the module name, its size, and how many other modules depend on it (the 'Used by' column).
insmod: Manually loads a module by specifying the full path to the .ko file. It is simple but does not handle dependencies automatically.
modprobe: The intelligent loader. It automatically resolves and loads any dependencies a module needs and also unloads modules with the -r flag. This is the command you will use 90% of the time.
rmmod: Removes (unloads) a module from the running kernel. It will fail if the module is in use.
modinfo: Shows detailed information about a module, such as its author, description, license, and parameters it accepts.
Your system also has configuration files that control module behaviour. The file /etc/modprobe.d/ contains configuration files (usually ending in .conf). Here you can blacklist a module (prevent it from loading automatically), set parameters for a module, or alias a device name to a specific module. For example, you might blacklist a buggy network driver and force the use of an alternative.
Probing hardware is about discovering what devices are connected to the system. The tool 'lspci' lists all PCI devices (like graphics cards, network adapters). 'lsusb' lists USB devices. 'lscpu' shows CPU information. But the most powerful tool for hardware configuration is 'udev' (userspace device management).
Udev is a system that runs in the background and listens for hardware events (like a USB drive being plugged in). When a device is detected, udev creates a file in the /dev/ directory (like /dev/sda for a hard drive) and loads the appropriate kernel module automatically. This is why your USB printer works when you plug it in without any manual command.
The /sys/ directory is a virtual filesystem that exposes kernel data structures. You can explore /sys/class/ to see devices grouped by their type (network, sound, etc.). This is useful for scripting and troubleshooting.
Finally, the concept of 'dependency' is critical. A module might rely on another module to work. For example, a filesystem module (like ext4) depends on the 'jbd2' journaling module. When you use modprobe to load ext4, modprobe automatically loads jbd2 first. The dependency map is stored in /lib/modules/$(uname -r)/modules.dep. You can rebuild this map using the 'depmod' command, which you should run after installing a new module manually.
Check Current Module Status
Run 'lsmod' to see a list of all currently loaded kernel modules. Pay attention to the 'Used by' column to see which modules depend on others. This is your baseline before making any changes.
Identify the Hardware
Use 'lspci', 'lsusb', or 'lsblk' to identify the specific hardware device that needs support. For example, 'lspci | grep -i ethernet' finds the network card. Note the vendor and device IDs—they help you find the correct module.
Find the Correct Module
Either check the Linux hardware compatibility database online or use 'modinfo' on a suspected module name. For example, if you have an Intel Ethernet adapter, you might guess the module is 'e1000' or 'igb'. 'modinfo e1000' will confirm if it exists and show a description.
Load the Module
Use 'sudo modprobe module_name' (e.g., 'sudo modprobe e1000'). This command checks the dependency map in /lib/modules, loads any required modules first, and then loads your target module. Alternatively, use 'sudo insmod /path/to/module.ko' but only if you want to skip dependency checking.
Verify the Module Loaded and Configure Persistence
Run 'lsmod | grep module_name' to confirm it loaded. Check 'dmesg | tail' for kernel messages about the device. If the module needs to load automatically every boot, either let udev handle it (if the device is plug-and-play) or add the module name to a file in /etc/modules-load.d/ (one module name per line). If you need to set specific parameters, add an 'options' line in /etc/modprobe.d/.
Imagine you are an IT administrator at a mid-sized company that runs its customer database on a Linux server. One Tuesday morning, the help desk starts receiving tickets: 'The external backup hard drive plugged into the server is not being recognised.'
You SSH into the server. You do not want to reboot because that would take the database offline for ten minutes, costing the company revenue. Your first step is to look at what the kernel currently knows. You type 'lsusb' to see if the USB bus detects the drive. It does not appear. Then you check 'lspci' to see if the USB controller card is visible. It is. You then run 'lsmod' and notice that the 'xhci_hcd' (USB 3.0 host controller) module is not loaded.
You suspect the module was accidentally blacklisted during a recent update. You check /etc/modprobe.d/ and find a file called 'blacklist-usb.conf' left by a previous intern. You remove the 'blacklist xhci_hcd' line from that file.
Now you need to load the module without a reboot. You run 'sudo modprobe xhci_hcd'. The module loads, and the kernel immediately detects the USB controller. You then run 'dmesg | tail' to see the kernel's log messages confirming the device is recognised. The backup drive appears as /dev/sdc.
But wait—the drive has a specific filesystem (say, XFS) that is not compiled into the kernel. You check 'cat /proc/filesystems' and do not see XFS listed. You load the XFS module: 'sudo modprobe xfs'. Now you mount the drive.
A week later, the company upgrades its network to 10 Gigabit Ethernet. You install a new network card in the server's PCIe slot. Instead of building a new kernel, you simply run 'sudo modprobe ixgbe' (the Intel 10GbE driver module) and configure the IP address. The card works immediately.
In this real-world scenario, the module system saved you from:
Rebooting a production server (downtime).
Learning how to compile a custom kernel.
Having to predict every piece of hardware in advance.
The key commands you used in this scenario were: - lsmod: to check the current state. - modprobe: to load modules intelligently. - dmesg: to read kernel logs for debugging. - /etc/modprobe.d/: to manage persistent module settings.
The LPIC-1 exam objective 101.3 is very hands-on and command-focused. You will not be asked to write code or to compile a kernel. The exam tests your ability to manage modules and configure devices using standard command-line tools.
Here is what they love to test:
The difference between insmod, modprobe, and modprobe -r. A classic trap question: 'Which command loads a module and its dependencies?' The answer is modprobe. insmod does NOT resolve dependencies. They will give you a scenario where a module fails to load because of an unmet dependency, and they expect you to know to use modprobe.
The /etc/modprobe.d/ configuration directory. They love asking about the 'blacklist' option. A typical question: 'How do you prevent the kernel from loading the psmouse module automatically during boot?' Answer: Create a file in /etc/modprobe.d/ with the line 'blacklist psmouse'.
The location of modules. They ask: 'Where are kernel modules stored for the currently running kernel?' Answer: /lib/modules/$(uname -r)/. Do not forget the uname -r part—the modules are tied to a specific kernel version.
lsmod output interpretation. They will show you the first line of lsmod output and ask: 'Which module is being used by another module?' The 'Used by' column shows this.
The purpose of depmod. They ask: 'What command updates the module dependency map?' Answer: depmod. You must run it after manually installing a module.
module parameters. A module like 'usbcore' can take parameters (e.g., 'autosuspend'). They ask: 'How do you set a parameter permanently for a module?' Answer: Add 'options module_name parameter=value' in a file in /etc/modprobe.d/.
The role of udev. They ask: 'What service creates device nodes in /dev/ at boot and when devices are plugged in?' Answer: udev (or the systemd-udevd service).
Probing commands: lspci, lsusb, lscpu. They ask you to identify which command lists SCSI devices (lsblk or lsscsi) or what 'lsusb -t' shows (a tree of USB devices).
The /sys/ and /proc/ virtual filesystems. They ask: 'Where would you find information about the kernel's current modules in a filesystem format?' Answer: /proc/modules (which is the same data as lsmod). And /sys/module/ contains the live module parameters.
Common traps:
Confusing /etc/modprobe.d/ with /etc/modules-load.d/. The latter is for loading modules at boot (by listing module names), not for configuration or blacklisting.
Thinking insmod can handle dependencies. It cannot.
Not knowing that modprobe -r removes a module and its dependencies (if they are no longer needed).
Forgetting to run depmod after adding a module to /lib/modules.
Memorise these exact command pairs: 'modprobe module_name' vs 'insmod /full/path/to/module.ko'. In the exam, pathnames matter—insmod requires a full path; modprobe works with the module name alone.
A kernel module is a piece of code that can be added to or removed from the running Linux kernel without rebooting.
The modprobe command is the preferred tool for loading modules because it automatically handles dependencies.
Kernel modules are stored in /lib/modules/$(uname -r)/ and are specific to one kernel version.
The /etc/modprobe.d/ directory controls module behaviour, including blacklisting and setting parameters.
Device files in /dev/ are created by udev, which is triggered by kernel events when hardware is detected.
Use lspci and lsusb to probe the hardware inventory on a system, and lsmod to see which modules are loaded.
The depmod command rebuilds the module dependency map and must be run after manually adding a module.
Modules that are compiled into the kernel statically are not visible in lsmod and cannot be removed.
These come up on the exam all the time. Here's how to tell them apart.
insmod
Requires full path to the .ko file.
Does not automatically resolve dependencies.
Fails if a dependency is missing.
modprobe
Works with module names only, not full paths.
Automatically loads required dependencies.
Recommended for routine module loading.
Building a driver into the kernel statically
Driver is compiled inside the kernel binary.
Cannot be removed without recompiling and rebooting.
Better for boot-critical drivers (e.g., root filesystem).
Using a loadable kernel module
Driver is a separate .ko file loaded at runtime.
Can be loaded/unloaded without reboot.
Saves memory if the driver is rarely used.
/etc/modprobe.d/
For configuration: blacklists, options, aliases.
Uses 'blacklist', 'options', 'alias' directives.
Managed by the modprobe tool.
/etc/modules-load.d/
For listing module names to load at boot.
Each line is the module name to auto-load.
Managed by systemd-modules-load.
lsmod
Lists currently loaded modules with sizes and usage.
Reads /proc/modules.
No details about the author or parameters.
modinfo
Shows details about a module, including dependencies, parameters, and licence.
Reads the .ko file itself.
Useful for learning about a module before loading it.
Mistake
You have to restart the computer every time you add or remove a kernel module.
Correct
Kernel modules are designed to be hot-pluggable. You can load and unload most modules using modprobe and rmmod while the system is running, with no reboot required. Only modules that change core kernel structures (like memory management) may need a reboot.
This misconception comes from experience with older operating systems like Windows 95 or early Mac OS, where installing a driver always required a reboot. New users carry that expectation over to Linux.
Mistake
Kernel modules are the same as regular software packages like a web browser or a text editor.
Correct
Kernel modules are not user-space applications. They run in kernel space with full privileges. They are written in C and compiled specifically for the exact version of the kernel you are running. You do not 'install' a module with apt or yum like you install Firefox; you may install it via a package, but it remains a kernel component.
Users see a package manager install something called 'linux-modules-extra-...' and assume it works like any other application. They do not realise that a module runs at a higher privilege level and can crash the entire system if buggy.
Mistake
If I remove a kernel module for a device, the device will be permanently broken.
Correct
Removing a module only unloads its code from the running kernel. The device itself is not damaged. You can reload the module at any time (modprobe device_name), or the next reboot will automatically load it again if it is configured to do so.
This fear stems from a misunderstanding of the relationship between software and hardware. Users equate 'unloading the driver' with 'uninstalling the driver permanently'.
Mistake
lsmod and modprobe are the same program.
Correct
lsmod is a simple script that reads /proc/modules and formats the output. modprobe is a complex program that reads /lib/modules/ and automatically resolves dependencies. They serve completely different purposes: one lists, one loads/unloads.
Both commands start with 'mod' and are often typed in sequence (lsmod to check, then modprobe to load), leading beginners to think they are from the same package or have similar functionality.
Mistake
The /etc/modprobe.d/ directory is for loading modules at boot time.
Correct
/etc/modprobe.d/ is for module configuration—specifically options, aliases, and blacklists. The directory /etc/modules-load.d/ is the one where you place file names to force modules to load at boot. Confusing these two is a common exam trap.
Both directories have similar names and are related to modules. Beginners skim the documentation and assume 'modprobe.d' handles loading because the name includes 'modprobe'.
Mistake
All hardware devices require a kernel module to function.
Correct
Some critical hardware drivers are compiled directly into the kernel (built-in) and do not appear in lsmod. These are marked with a '['bracket']' in the kernel configuration. Devices like the root filesystem driver or the primary serial console are often built-in so they work from the very first moment of booting.
Beginners learn about modules and assume everything is a module. They forget that the kernel itself contains a small, static core that includes essential drivers.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
insmod manually loads a module by specifying its exact file path but does not load dependencies. modprobe loads a module by name, automatically resolves and loads dependencies, and can also unload modules with the -r flag.
Create a .conf file in /etc/modprobe.d/ (e.g., /etc/modprobe.d/blacklist.conf) and add the line 'blacklist module_name' where module_name is the exact name of the module as shown by lsmod.
depmod builds the modules.dep file that maps module dependencies. You should run it after adding new module .ko files to /lib/modules/ to ensure modprobe can find and load them correctly.
Use 'modinfo -p module_name' or look in /sys/module/module_name/parameters/ after the module is loaded. The modinfo command shows the parameter names and descriptions directly.
udev is a device manager that runs in user space. It listens for kernel events (like plugging in a USB drive) and then loads the appropriate kernel module, creates the device file in /dev/, and runs any custom rules you have defined.
The module is being used by another process, another module, or a filesystem. Check the 'Used by' column in lsmod to see which module or process holds the reference. You must stop that reference before unloading.
No. The kernel itself relies on some modules for essential functionality (like the root filesystem driver). Removing critical modules will crash the system. Always check dependencies before removing.
You've finished Kernel Modules and Hardware Configuration. Continue through the LPIC-1 study guide to build a complete picture of the exam.
Done with this chapter?