Hands-on Lab·LPIC-1

Kernel modules, devices and udev

Objective 101.1 names modprobe, lsmod, /dev, /sys and udev as things you should be able to talk about. This guide lists what the running kernel has loaded, reads a module's own description off disk, loads and removes one that cannot affect anything, and then looks at where device nodes and predictable interface names actually come from.

101: System Architecture Guide 33 of 33 Beginner

OSUbuntu 26.04 LTS
Kernel7.0.0-30-generic
systemd259
TimeAbout 22 min

The Debian-family host. The only module loaded is `dummy`, whose documented purpose is to discard every packet sent to it.
Server Name	IP Address	OS	Roles	CPU	RAM	HDD
LPIC1-A01	192.168.0.76	Ubuntu 26.04 LTS	Debian-family host - dpkg and apt, which objective 102.4 names	2 Core	4 GB	50 GB

This guide includes

Use this when hardware is present and not working, or when you need to know whether support for something is compiled in, loadable, or blacklisted. This matters because a device that does not appear is usually a module question, and because /dev and /sys are the two places the answer is written down.

reading lsmod including the Used by column
finding a module's file on disk and reading its description with modinfo
previewing what modprobe would do before doing it
loading and removing a module, and confirming both with a count
reading a major and minor device number out of ls -l
knowing where a module is blacklisted and where one is requested at boot

Before you start

targets-runlevels-and-what-the-kernel-found

What the kernel has loaded right now
A count, a table, and the directory the files came from.
bash Example session
```
$lsmod | wc -l; echo "modules loaded"; lsmod | head -452modules loadedModule                  Size  Used byudp_diag               12288  0tcp_diag               20480  0inet_diag              24576  2 tcp_diag,udp_diag$uname -r; ls -d /lib/modules/$(uname -r); ls /lib/modules/$(uname -r)/kernel/ | head -5; echo "--- modules are files on disk, grouped like the kernel source"7.0.0-30-generic/lib/modules/7.0.0-30-genericarchblockcryptodriversfs--- modules are files on disk, grouped like the kernel source
```
Note
The Used by column is a reference count and a list. inet_diag is used by two other modules and names them, which is why it cannot be removed until they are. A module showing 0 and nothing after it is safe to unload.

Modules are per-kernel-version. The directory is /lib/modules/$(uname -r)/, so a kernel upgrade brings an entirely new tree - and a module built by hand for the old kernel does not follow it. That is what DKMS exists to automate.

The subdirectories mirror the kernel source layout, which is how you find something by category rather than by guessing: network drivers under kernel/drivers/net/, filesystems under kernel/fs/.

52 is a small number because this is a virtual machine. Physical hardware loads far more. A driver compiled INTO the kernel never appears in lsmod at all - grep CONFIG_X /boot/config-$(uname -r) distinguishes y (built in) from m (a module).

Expected result52 modules, with inet_diag showing 2 tcp_diag,udp_diag in its Used by column - kernel 7.0.0-30-generic, and its module tree grouped into arch, block, crypto, drivers, fs.

Success conditionYou can list a running kernel's modules and find them on disk.
What one module says about itself
The file, its description, and a dry run.
bash Example session
```
$modinfo dummy | grep -E "^(filename|description|license|depends|parm)" | head -6filename:       /lib/modules/7.0.0-30-generic/kernel/drivers/net/dummy.ko.zstdescription:    Dummy netdevice driver which discards all packets sent to itlicense:        GPLdepends:parm:           numdummies:Number of dummy pseudo devices (int)$modprobe -n -v dummy; echo "--- -n is a dry run: this is what WOULD be loaded, dependencies first"insmod /lib/modules/7.0.0-30-generic/kernel/drivers/net/dummy.ko.zst numdummies=0--- -n is a dry run: this is what WOULD be loaded, dependencies first
```
Note
.ko.zst is a compressed module, which is now the default on both families. Looking for dummy.ko and finding nothing is not a missing module - modinfo resolves the name regardless of compression.

modinfo reads the file and loads nothing. It is safe on any module, including ones you have no intention of using. modinfo -F filename prints just the path.

parm: lines are the module's accepted options, with type. They are passed as modprobe name=value, or set permanently with an options line in /etc/modprobe.d/.

modprobe -n -v is the dry run, and the habit worth forming. It expands to the actual insmod calls in dependency order, so you see everything that would be loaded before anything is.

depends: empty means nothing else is needed. When it is not empty, modprobe loads those first and insmod does not - which is the entire practical difference between the two commands.

Expected resultfilename: /lib/modules/7.0.0-30-generic/kernel/drivers/net/dummy.ko.zst, described as Dummy netdevice driver which discards all packets sent to it, depends: empty, and a parm: for numdummies. The dry run prints the insmod it would perform.

Success conditionYou can find out what a module does before loading it.
Loading one that cannot affect anything
A module in, an interface out, and what the kernel then exposes about it.
bash Example session
```
$lsmod | grep -c "^dummy "; echo "dummy modules loaded before"; sudo modprobe dummy numdummies=1 && lsmod | grep "^dummy"; ip -br link show type dummy 2>/dev/null | head -20dummy modules loaded beforedummy                  16384  0dummy0           DOWN           6e:75:0d:1e:13:9e <BROADCAST,NOARP>$ls /sys/module/dummy/; echo "--- refcnt:"; cat /sys/module/dummy/refcnt; ls /sys/module/dummy/parameters/ 2>/dev/null || echo "(this module exposes no parameters at runtime)"coresizeholdersinitsizeinitstatenotesrefcntsectionssrcversiontaintuevent--- refcnt:0(this module exposes no parameters at runtime)
```
Note
A module is code the kernel gains at runtime. Loading dummy created a working network interface out of nothing, with no hardware behind it. That is the whole idea - drivers are not compiled in for hardware the machine may never have.

/sys/module// is the kernel's own view of it, one file per attribute. refcnt is what lsmod shows as Used by, and initstate says whether it is live.

There is no parameters directory here, even though modinfo listed a parm. Only parameters the module marks readable are exposed at runtime. So modinfo tells you what can be SET at load time, and /sys/module/.../parameters/ tells you what can be read back afterwards - and they are not the same list.

and DOWN are the honest description of a dummy interface. It has a MAC address and will accept configuration, and every packet stops there. That is what makes it the standard safe target for network experiments on a machine you are connected to.

Expected result0 before - then dummy loaded at 16384 bytes and a new dummy0 DOWN interface with <BROADCAST,NOARP> - and /sys/module/dummy/ holding refcnt, coresize, initstate and others, with refcnt 0 and no parameters directory at all.

Success conditionYou can load a module and see the device it creates.
The device tree that is not on a disk
Two numbers instead of a size, and one file per attribute.
bash Example session
```
$ls -l /dev/null /dev/zero | awk '{print $1, $5, $6, $NF}'; echo "--- the two numbers where a size would be are the major and minor device numbers"crw-rw-rw- 1, 3 /dev/nullcrw-rw-rw- 1, 5 /dev/zero--- the two numbers where a size would be are the major and minor device numbers$ls /sys/class/net/; echo "---"; cat /sys/class/net/eth0/address; cat /sys/class/net/eth0/mtu; echo "--- one file per attribute, which is what sysfs is"dummy0eth0lo---00:15:5d:01:11:721500--- one file per attribute, which is what sysfs is$udevadm info -q property -p /sys/class/net/eth0 2>/dev/null | grep -E "ID_NET_NAME|DEVPATH|INTERFACE" | head -4DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/VMBUS:01/1c3c68f3-d116-4fbe-9f64-e4dcdca05832/net/eth0INTERFACE=eth0ID_NET_NAME_MAC=enx00155d011172ID_NET_NAME=eth0
```
Note
c is a character device and the two numbers replace the size. Major identifies the driver - 1 is the memory driver for both of these - and minor identifies which device it handles. b is a block device; ls -l /dev/sda shows the same shape.

/dev is created at boot by udev, not stored on disk. It is a tmpfs populated from kernel events, which is why an unplugged device's node disappears and why mknod is almost never the right answer.

sysfs is one value per file on purpose. cat /sys/class/net/eth0/address for the MAC, .../mtu for the MTU - no parsing, and it is what ip and ethtool read underneath.

ID_NET_NAME_MAC is where predictable interface names come from. udev offers several candidate names derived from the MAC, the PCI slot or the firmware index, and a rule picks one. That is why interfaces are called enp0s3 rather than eth0 on most modern systems - this VM keeps eth0 because a kernel parameter disables the scheme.

udevadm info is the tool for "why is this device called that", and udevadm monitor shows events live while you plug something in.

Expected resultcrw-rw-rw- with 1, 3 for /dev/null and 1, 5 for /dev/zero - /sys/class/net/ listing dummy0, eth0, lo with the MAC and MTU each in its own file - and udevadm reporting ID_NET_NAME=eth0 alongside ID_NET_NAME_MAC=enx00155d011172.

Success conditionYou can read a device node's identity and find its attributes in sysfs.
What stops a module loading
Two directories - one that prevents, one that requests.
bash Example session
```
$ls /etc/modprobe.d/ | head -4; grep -rhE "^(blacklist|install|options)" /etc/modprobe.d/ 2>/dev/null | head -4; echo "--- blacklist and options both live here"amd64-microcode-blacklist.confblacklist-ath_pci.confblacklist-firewire.confblacklist-framebuffer.confblacklist evbugblacklist usbmouseblacklist usbkbdblacklist eepro100--- blacklist and options both live here$ls /etc/modules-load.d/ 2>/dev/null; cat /etc/modules 2>/dev/null | grep -vE "^#|^$" | head -3; echo "--- and this is where a module is asked for at boot"modules.conf--- and this is where a module is asked for at boot
```
Note
/etc/modprobe.d/ controls HOW a module loads; /etc/modules-load.d/ asks for one at boot. Two directories, opposite jobs, and confusing them is a common mistake.

blacklist is weaker than it sounds. It stops automatic loading by alias, and does NOT stop modprobe typed by hand or a dependency pulling it in. To block it completely use install /bin/false.

options key=value in the same directory is how a parameter is made permanent, rather than being typed on every modprobe.

Changes here need the initramfs rebuilt if the module loads during early boot - update-initramfs -u on the Debian family, dracut -f on the RPM one. A blacklist that appears to be ignored is very often this.

Expected resultblacklist-*.conf files under /etc/modprobe.d/ with entries such as blacklist evbug, blacklist usbmouse, blacklist eepro100 - and modules.conf under /etc/modules-load.d/.

Success conditionYou can find out whether a module is being prevented from loading.
Putting the machine back
The module out, and the counts on both sides of it.
bash Example session
```
$sudo ip link del dummy0 2>/dev/null; sudo modprobe -r dummy && lsmod | grep -c "^dummy "; echo "dummy modules loaded after"; ip -br link show type dummy 2>&1 | tail -10dummy modules loaded after$lsmod | wc -l; echo "modules loaded"; ip -br link show | head -2; ls /sys/module/dummy 2>&1 | tail -152modules loadedlo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>eth0             UP             00:15:5d:01:11:72 <BROADCAST,MULTICAST,UP,LOWER_UP>ls: cannot access '/sys/module/dummy': No such file or directory
```
Note
modprobe -r removes a module and anything it pulled in; rmmod removes only the one named. Either fails while the reference count is above zero, which is the kernel refusing to unload code that is in use rather than a permissions problem.

52 before and 52 after is the check. The count is a single number covering the whole kernel, which is easier to trust than looking for one name.

/sys/module/dummy disappearing is the second, independent proof - the directory only exists while the module is loaded.

And eth0 is confirmed still UP. A page that loads a network driver on a machine reached over the network should say plainly that the real interface is untouched.

Expected result0 dummy modules after removal, back to 52 modules, lo and eth0 alone with eth0 still UP, and /sys/module/dummy No such file or directory.

Success conditionThe kernel is carrying exactly what it was before.

Troubleshooting

A device is present and no driver seems to be handling it.

Why: The module is not loaded, not installed, or blacklisted.

Fix:lspci -k shows the kernel driver in use per device. If none, modinfo <module> to check it exists, modprobe <module> to try it, and grep -r <module> /etc/modprobe.d/ to see whether something is blocking it.
modprobe -r reports the module is in use.

Why: Its reference count is above zero - another module or an open device depends on it.

Fix:lsmod | grep <module> and read the Used by column, which names the dependants. Remove those first, or stop whatever has the device open.
A blacklisted module loads anyway.

Why: blacklist only prevents automatic loading by alias. A dependency or an explicit modprobe still loads it, and early-boot modules come from the initramfs.

Fix:Use install <module> /bin/false in /etc/modprobe.d/, then rebuild the initramfs: sudo update-initramfs -u or sudo dracut -f.
A module parameter set with modprobe is gone after a reboot.

Why: It applied to that load only.

Fix:Put options <module> key=value in a file under /etc/modprobe.d/, and rebuild the initramfs if the module loads during early boot.
A network interface changed name after a hardware or kernel change.

Why: Predictable interface names are derived by udev from the PCI slot, firmware index or MAC, and the inputs changed.

Fix:udevadm info -q property -p /sys/class/net/<name> lists every candidate name. Pin one with a rule in /etc/systemd/network/, or use net.ifnames=0 on the kernel command line to keep the old scheme.
A module file cannot be found under /lib/modules.

Why: Modules are compressed as .ko.zst or .ko.xz, and are per kernel version.

Fix:modinfo -F filename <module> resolves the real path regardless of compression. Check you are looking under /lib/modules/$(uname -r)/ and not an older kernel's tree.

Official sources

← All LPIC-1 guides

Kernel modules, devices and udev

This guide includes

Before you start

What the kernel has loaded right now

What one module says about itself

Loading one that cannot affect anything

The device tree that is not on a disk

What stops a module loading

Putting the machine back

Troubleshooting

Official sources