Linux Kernel Modules and Devices

Linux device discovery is a conversation between the kernel and userspace. The kernel detects hardware, exposes device state through sysfs, creates or requests device nodes, and can request module loading. Userspace tools such as systemd-udevd and modprobe apply policy: permissions, names, symlinks, module options, and helper actions.

Command Examples

lsmod
modinfo <module>
modprobe --show-depends <module>
cat /proc/modules
find /sys -name modalias -print | head
udevadm info --query=all --name=/dev/sda | head
dmesg -T | grep -i -E 'module|firmware|udev|driver|taint'

Example output and meaning:

Command Example output What it does
lsmod Module names, sizes, and use counts. Shows loaded kernel modules before changing drivers.
modinfo <module> Module filename, version, aliases, firmware, and parameters. Shows module metadata and hardware matching.
modprobe --show-depends <module> Dependency list or module load errors. Shows what would load before changing kernel module state.

These commands separate loaded modules, module metadata, dependency resolution, kernel-visible module state, device aliases, udev properties, and kernel messages.

Built-In vs Loadable Modules

A driver can be built into the kernel image or compiled as a loadable module. Built-in drivers are available as soon as the kernel initializes that subsystem. Loadable modules can be inserted later by initramfs, udev, a service, or an admin command.

Type Operational Meaning
Built-in No .ko file is loaded at runtime; options must usually come from the kernel command line.
Loadable module modprobe can load it with dependencies and options from /etc/modprobe.d/.
DKMS module Rebuilt outside the kernel tree for each kernel ABI; can fail after kernel upgrades.
Signed module Required on many Secure Boot systems unless policy allows unsigned modules.

Do not assume lsmod lists every driver in use. Built-in drivers do not appear as loaded modules. Check /sys, dmesg, lspci -k, ethtool -i, or subsystem-specific tools when the module list is not enough.

modprobe, Aliases, and Parameters

modprobe loads modules by name or alias and resolves dependencies. Unlike insmod, it understands dependency and alias metadata generated by depmod.

Common policy files live under /etc/modprobe.d/:

Directive Use
options module key=value Set module parameters when loaded through modprobe.
blacklist module Prevent normal alias-based automatic loading.
install module command... Override module loading with a command wrapper. Use sparingly.
softdep module pre: a b post: c Express weak ordering dependencies.

Module parameters can also come from the kernel command line. Parameters for built-in modules must be supplied there because no later modprobe event loads them. For loadable modules, modprobe also consults the kernel command line for module-prefixed options.

Check parameters:

modinfo -p <module>
cat /sys/module/<module>/parameters/* 2>/dev/null

Device Model: sysfs, devtmpfs, and udev

Three paths are easy to confuse:

Path Role
/sys sysfs view of kernel devices, buses, drivers, module parameters, and topology.
/dev device nodes applications open, usually backed by devtmpfs plus udev naming and permissions.
/run/udev udev runtime database and state.

The kernel publishes device metadata including modalias strings. udev can match those events, call modprobe, set ownership and mode, and create stable symlinks such as /dev/disk/by-id/ and /dev/disk/by-uuid/.

Device nodes have major and minor numbers. The major number selects a driver or device class; the minor number identifies an instance or subdevice. Modern systems mostly let devtmpfs and udev create nodes automatically, but understanding major/minor numbers helps when a stale node exists or a container exposes a device incorrectly.

udev Rule Examples and Rename Failures

Use udev for stable names, permissions, tags, and symlinks. Prefer stable symlinks over renaming kernel device nodes; kernel names such as sdb, eth0, and video0 can change with probe order.

Example storage symlink rule:

# /etc/udev/rules.d/60-app-disk.rules
SUBSYSTEM=="block", ENV{ID_SERIAL}=="Samsung_SSD_1234", SYMLINK+="disk/app-data", OWNER="postgres", GROUP="postgres", MODE="0660"

Example USB serial adapter rule:

# /etc/udev/rules.d/70-console-cable.rules
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="tty/console-lab", GROUP="dialout", MODE="0660"

Reload and test without rebooting:

udevadm control --reload
udevadm trigger --subsystem-match=block
udevadm test /sys/class/block/sdb 2>&1 | less
udevadm info --query=property --name=/dev/sdb

Common device rename failure cases:

Failure Why It Happens Safer Pattern
Rule matches KERNEL=="sdb" Kernel enumeration order changes after reboot, hotplug, or driver timing. Match serial, WWN, filesystem UUID, or by-id properties.
Network interface rename races Multiple .link files, predictable names, or driver-created names conflict. Use systemd .link policy with stable MAC/path matches and inspect udevadm test-builtin net_setup_link.
Rule depends on parent attribute from wrong level ATTR{} matches current device; ATTRS{} walks parents. Check udevadm info -a -n <device> and match the correct level.
Rule is not in initramfs Early boot storage, crypto, or network device needs the rule before root mounts. Rebuild initramfs after changing early-device rules.
Symlink points to old device Device was replaced, cloned, or serial/UUID duplicated. Audit /dev/disk/by-*, blkid, and physical serials after replacement.
Container sees host node but not device access Device cgroup or permissions deny opens even when /dev entry exists. Check runtime device allow rules, groups, and cgroup device policy.

initramfs and Early Devices

The real root filesystem may require modules before /usr or the normal root is available: storage HBA, NVMe, USB storage, filesystem, LVM, md RAID, dm-crypt, or network boot support. Those modules, firmware files, udev rules, and helper binaries must exist in initramfs if they are needed before root is mounted.

Boot failures often happen because the normal system has the right module, but the initramfs image does not.

Initramfs checks:

lsinitrd 2>/dev/null | grep -E '<module>|firmware|crypt|lvm|mdadm'
lsinitramfs /boot/initrd.img-$(uname -r) 2>/dev/null | grep -E '<module>|firmware|crypt|lvm|mdadm'
cat /proc/cmdline

After changing drivers, storage configuration, encryption, or root filesystem dependencies, rebuild initramfs using the distro tool before rebooting.

Failure Modes

Symptom Likely Boundary Checks
Hardware visible but no driver Missing module, blacklist, unsupported ID, Secure Boot rejection. lspci -k, modprobe -v, dmesg, /etc/modprobe.d/.
Module loads but device absent Firmware, probe failure, wrong bus state, missing dependency. dmesg, modinfo, /sys/bus/*/devices.
Works after boot but not during boot Missing initramfs module, firmware, udev rule, or unlock helper. inspect initramfs, kernel command line, emergency shell.
Works on old kernel but not new DKMS build failure, ABI change, missing signed module. package logs, dkms status, journalctl -k.
Device path changed Kernel enumeration order or udev naming changed. use /dev/disk/by-id, UUIDs, labels, or logical mappings.
Container cannot use device Device node, cgroup device policy, permissions, or missing userspace library. container spec, /dev, groups, runtime logs.

Study Cards

Question

Why might a driver be active but absent from lsmod?

Answer

It may be built into the kernel instead of loaded as a module.

Question

What does modprobe add over insmod?

Answer

It resolves module dependencies, aliases, options, blacklists, and policy from modprobe configuration.

Question

What is a modalias used for?

Answer

It lets userspace map a discovered device to a matching kernel module alias.

Question

Why can a system boot fail after a storage driver change?

Answer

The running system may have the driver, but the initramfs may lack the module, firmware, or helper needed before root is mounted.

References