Hands-on Lab·LPIC-2
Kernel modules, and proving a parameter arrived
Topic 201 is one of the largest areas on the 201 paper. This guide works through the module tools in the order you would actually use them - find out what a module is before loading it, load it with a parameter, prove the parameter arrived, then take it back out - using dummy, which creates visible interfaces so the effect can be seen rather than assumed.
201: Linux Kernel Guide 4 of 29 Intermediate
- PlatformsUbuntu 26.04 LTS + AlmaLinux 10.2
- Block devicesone 50 GB disk
- TimeAbout 18 min
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| LPIC2-A01 | 192.168.0.78 | Ubuntu 26.04 LTS | Primary service host - BIND, Apache, Samba, Postfix. Topic 204 RAID runs on loop devices; this machine has no spare disk | 2 Core | 4 GB | 50 GB |
| LPIC2-B01 | 192.168.0.79 | AlmaLinux 10.2 | Second service host - nginx, NFS, DNS secondary, and the other family's spelling of each service | 2 Core | 4 GB | 50 GB |
This guide includes
Use this for one of the largest areas on the 201 paper. This matters because a module will not tell you whether your parameter arrived - you have to read it back from the kernel yourself.
- finding which kernel is running, and where its modules live
- reading what is loaded now, and asking about a module before loading it
- loading one with a parameter, and proving the parameter arrived
- seeing why modprobe exists, through dependencies
- unloading it, and confirming nothing was left behind
Before you start
- the-lab-a-service-needs-a-client
-
Which kernel is running, and where its modules live
-
What is loaded now
-
Asking about a module before loading it
-
Loading it with a parameter, and proving the parameter arrived
-
Dependencies, and why modprobe exists
-
Taking it back out