1.5Managing and Troubleshooting the Running Kernel

"The system does not recognize new hardware", "I need to tune a kernel parameter", "I need to diagnose a mystery crash"—these are all skills for interacting with the running kernel. As the closing subtopic of Exam 201, this section covers four practical tool groups: modules, procfs/sysfs, udev, and crash dumps.

1.5.1Working with kernel modules

• Inspection: lsmod (list loaded modules, a formatted view of /proc/modules), modinfo (show a module's details, parameters, and dependencies), and uname -r (check the running kernel version).
• Loading: modprobe (loads with dependency resolution, consulting /lib/modules/<kver>/modules.dep) vs insmod (loads a single module directly, with no dependency resolution). Unload with rmmod (or modprobe -r).
• depmod regenerates modules.dep (run this after adding new modules, etc.). /etc/modprobe.d/ is where per-module load options, aliases, and blacklist settings live.

1.5.2procfs/sysctl/sysfs and hardware/crash analysis

• /proc (procfs) is a virtual filesystem exposing kernel internal state as files. The tree under /proc/sys/kernel/ holds writable parameters, tuned with the sysctl command or made persistent via /etc/sysctl.conf//etc/sysctl.d/.
• /sys (sysfs) exposes the device/driver hierarchy as files. The division of labor: procfs is general kernel state, sysfs is centered on the device model.
• Hardware/failure inspection: dmesg (the kernel ring buffer, including boot-time messages), lspci (list PCI devices), lsusb (list USB devices), lsdev (device resource usage), and journalctl (the systemd journal, which can search dmesg-equivalent info alongside everything else).
• udev dynamically creates and manages /dev entries as devices are attached/detached. Rules live under /etc/udev/, and udevadm monitor lets you watch events in real time. For serious crash analysis, use kdump (captures a dump at crash time) and kexec (switches to another kernel without a full reboot—also how kdump boots its dedicated capture kernel).

Trace a typical troubleshooting flow. A newly added storage controller is not recognized: first check with lspci whether the device is even visible, then tail dmesg for driver load errors. Once you know the module, modprobe <module> loads it with dependencies resolved; confirm with lsmod and check parameters/description with modinfo <module>. If modprobe says it cannot find a module you just added, run depmod -a to regenerate modules.dep and retry. To stop a module from auto-loading for a specific device, blacklist it in /etc/modprobe.d/blacklist.conf. For tuning a kernel parameter—say, trying IP forwarding temporarily—use sysctl -w net.ipv4.ip_forward=1 (which really just writes /proc/sys/net/ipv4/ip_forward); to survive a reboot, write it to /etc/sysctl.d/99-forward.conf and apply with sysctl --system. If a USB device does not show up under /dev, check whether events are firing with udevadm monitor and suspect a mistake in the rules (/etc/udev/rules.d/). For recurring, unexplained kernel panics, pre-configuring kdump means that at crash time the system switches via kexec to a lightweight capture kernel, grabs a memory dump, and leaves it available for post-mortem analysis.

1.5.3Section summary

• Modules = modprobe (with dependencies) / insmod (direct) / rmmod; run depmod after adding modules to regenerate modules.dep
• Parameters = tune procfs (/proc/sys) via sysctl (persist under /etc/sysctl.d/); devices via sysfs/udev; crash analysis via kdump/kexec