2.1 Hardware Discovery, Sysfs, Procfs & Kernel Modules (101.1)

2.1 Hardware Discovery, Sysfs, Procfs & Kernel Modules

Quick Summary: Linux exposes system hardware and kernel runtime state through two pseudo-filesystems: /proc (process and kernel metrics) and /sys (sysfs device and driver hierarchy). Administrators query hardware using utilities like lspci, lsusb, lscpu, and lshw. Hardware drivers operate primarily as Loadable Kernel Modules (LKMs) located in /lib/modules/$(uname -r)/, managed dynamically via modprobe (dependency-aware) and configured persistently through files in /etc/modprobe.d/*.conf.

1. Virtual Filesystems for Hardware Inspection

The Linux kernel does not require traditional block storage to expose system metrics and hardware parameters. Instead, it generates virtual (pseudo) filesystems in RAM upon boot. Reading these files queries internal kernel data structures in real time, and writing to permitted files modifies live kernel behavior.

The /proc Filesystem (procfs)

Originally designed to present per-process information, /proc has expanded to expose comprehensive kernel status and hardware resources. Files in /proc report 0 bytes in ls -l output because their content is generated dynamically when read.

The /sys Filesystem (sysfs)

Introduced in Linux 2.6, /sys provides a strictly structured, object-oriented representation of the kernel's unified device model. While /proc contains unstructured text, /sys exposes devices, buses, drivers, and kernel subsystems as individual directories containing single-value attributes.

/sys/
├── block/        # Symlinks to all block devices (sda, nvme0n1, sr0)
├── bus/          # Bus topologies (pci, usb, i2c, scsi, platform)
│   ├── pci/devices/0000:00:1f.2/ -> ../../../devices/pci0000:00/...
│   └── usb/devices/1-1/ -> ../../../devices/pci0000:00/.../usb1/1-1
├── class/        # Subsystem classes (net, tty, sound, power_supply)
│   └── net/      # Symlinks to network interfaces (eth0, wlan0, lo)
├── devices/      # The root global device tree representing physical topology
├── fs/           # Filesystem-specific runtime attributes
├── kernel/       # Kernel variables and configuration points
├── module/       # Information on every loaded kernel module and its parameters
└── power/        # System power state and sleep controls

Exam Tip — File Attributes in /sys: You can interact directly with hardware states by echoing values into sysfs attribute files. For example, triggering a SCSI bus rescan without rebooting:

echo "1" > /sys/class/scsi_host/host0/scan

2. Hardware Detection Utilities

Linux provides dedicated CLI tools to probe specific hardware buses and summarize hardware configurations.

Probing PCI/PCIe Devices: lspci

lspci reads /proc/bus/pci and sysfs to display information about all devices connected to the PCI, PCI-X, and PCI Express buses (e.g., GPU, SATA/NVMe controllers, Ethernet, Wi-Fi adapters).

# Standard listing
$ lspci
00:00.0 Host bridge: Intel Corporation 11th Gen Core Processor Host Bridge/DRAM Registers (rev 01)
00:02.0 VGA compatible controller: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01)
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (13) I219-LM (rev 20)
01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller 980

Crucial lspci Command-Line Flags

• -k, --kernel: Shows kernel drivers handling each device and kernel modules capable of handling it. This is essential on the exam to determine which driver is actively attached.
• -v, -vv, -vvv: Increases verbosity, displaying subsystem IDs, memory address spaces (BARs), interrupt lines, latency, and power capabilities.
• -n: Displays numeric vendor and device codes (hexadecimal IDs) instead of looking up names in /usr/share/hwdata/pci.ids.
• -nn: Displays both textual descriptions and numeric hex IDs simultaneously (e.g., Intel Corporation Ethernet Connection [8086:15f9]).
• -s [[[[domain]:]bus]:]slot[.func]: Selects a specific device by its bus/slot/function address (e.g., lspci -s 00:1f.6 -k).
• -d [vendor]:[device]: Filters output by vendor/device ID in hex (e.g., lspci -d 8086: -k filters all Intel hardware).
• -t: Displays a physical bus tree topology.

$ lspci -s 00:1f.6 -k -nn
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (13) I219-LM [8086:15f9] (rev 20)
	Subsystem: Dell Device [1028:0a3c]
	Kernel driver in use: e1000e
	Kernel modules: e1000e

Probing USB Devices: lsusb

lsusb queries USB hub controllers and device descriptors via sysfs and the usbfs interface.

# Standard listing
$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 002: ID 04f2:b6d9 Chicony Electronics Co., Ltd Integrated Camera
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Crucial lsusb Command-Line Flags

• -v, --verbose: Dumps complete USB descriptor structures, including bInterfaceClass, endpoint addresses, max packet sizes, and power consumption.
• -t, --tree: Dumps physical USB device hierarchy as a tree showing bus numbers, root hubs, downstream ports, negotiated speeds (1.5M, 12M, 480M, 5000M, 10000M), and active driver bindings.
• -d [vendor]:[product]: Filters by hexadecimal vendor ID and product ID (e.g., lsusb -d 046d:c52b).
• -s [[bus]:][devnum]: Selects devices by bus and/or device address number.

$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
    |__ Port 3: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M
    |__ Port 5: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M

System-Wide Summaries: lscpu and lshw

• lscpu: Collects CPU architecture details from /proc/cpuinfo and sysfs path /sys/devices/system/cpu/. It summarizes socket count, core count, threads per core, NUMA nodes, virtualization acceleration (VT-x / AMD-V), CPU caches (L1d, L1i, L2, L3), and byte order (Little Endian).
• lshw: Generates a detailed hierarchical report of all hardware components (motherboard, memory banks, PCI slots, disks, network interfaces). Useful options include lshw -short (compact summary table), lshw -class network (filters by device class), and lshw -html or lshw -xml (outputs structured formats).

3. Kernel Modules Architecture & Management

The Linux kernel is monolithic with dynamic modularity. Rather than compiling every possible driver directly into the kernel binary (vmlinuz), the kernel uses Loadable Kernel Modules (LKMs). Modules are object code files with .ko (Kernel Object) or .ko.xz / .ko.zst (compressed) extensions that can be loaded into kernel memory and unloaded on demand without rebooting.

Module Directory Structure

Modules corresponding to the running kernel version reside under /lib/modules/$(uname -r)/:

/lib/modules/5.15.0-88-generic/
├── kernel/                     # Kernel driver hierarchy
│   ├── arch/                   # Architecture-specific modules
│   ├── crypto/                 # Cryptographic algorithms
│   ├── drivers/                # Hardware device drivers (net, scsi, gpu, usb)
│   │   ├── net/ethernet/intel/e1000e/e1000e.ko
│   │   └── block/virtio_blk.ko
│   └── fs/                     # Filesystem drivers (ext4, xfs, btrfs, nfs)
├── modules.dep                 # Dependency map generated by depmod
├── modules.dep.bin             # Binary indexed version of modules.dep
├── modules.alias               # Hardware and protocol alias mappings
├── modules.builtin             # List of drivers compiled statically into the kernel
└── modules.symbols             # Exported kernel symbol lookup table

Exam Trap: If you install a new kernel version, its modules are placed in /lib/modules/<new_version>/. Until you reboot into that kernel, uname -r outputs the currently active kernel, and tools like modprobe search /lib/modules/$(uname -r)/ by default.

4. Kernel Module Management Utilities

1. lsmod

lsmod formats /proc/modules into a clean table containing three columns:

$ lsmod
Module                  Size  Used by
e1000e                290816  0
ptp                    32768  1 e1000e
vfat                   24576  1
fat                    86016  1 vfat
ext4                  983040  2

• Module: The name of the loaded kernel module.
• Size: Memory footprint of the module in bytes.
• Used by: The number of current instances referencing the module, followed by the names of dependent modules using it. A module cannot be unloaded if its reference count is greater than 0.

2. modprobe

modprobe is the primary tool for loading and unloading modules. It automatically resolves module dependencies by consulting /lib/modules/$(uname -r)/modules.dep.bin.

Essential modprobe Commands and Flags

• modprobe <module_name>: Loads the specified module and all prerequisites.
• modprobe -r <module_name>: Removes (unloads) the module and its unused dependencies (equivalent to --remove).
• modprobe -v <module_name>: Verbose mode; prints insmod actions as they occur.
• modprobe -c: Dumps the effective aggregated module configuration from all configuration files.
• modprobe -n or --dry-run: Simulates the operations without actually inserting or removing modules.
• modprobe -D or --show-depends: Displays the dependency chain of a module without loading it.
• modprobe -a <module1> <module2>: Loads multiple modules specified on the command line.
• modprobe -f: Forces insertion (ignores kernel version checks — dangerous).

# Check dependencies of the ext4 filesystem module
$ modprobe -D ext4
insmod /lib/modules/5.15.0-88-generic/kernel/fs/mbcache.ko
insmod /lib/modules/5.15.0-88-generic/kernel/fs/jbd2/jbd2.ko
insmod /lib/modules/5.15.0-88-generic/kernel/crypto/crc32c_generic.ko
insmod /lib/modules/5.15.0-88-generic/kernel/fs/ext4/ext4.ko

# Unload a module safely with its unused dependencies
$ sudo modprobe -r e1000e

3. insmod vs rmmod

• insmod: A low-level tool that inserts an unlinked .ko object directly into the kernel. It does not check /lib/modules/, does not read modules.dep, and fails with Unknown symbol in module if any dependent module is missing.

  # Requires exact path to the module file
  sudo insmod /lib/modules/5.15.0-88-generic/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko
  

• rmmod: Unloads a module by its module name (not file path). It will fail if the module is in use or if another loaded module depends on it.

  # Options: -f (force unload), -v (verbose), -s (log to syslog)
  sudo rmmod e1000e
  

4. modinfo

modinfo extracts metadata from .ko files or by querying the module name of loaded/available drivers.

$ modinfo e1000e
filename:       /lib/modules/5.15.0-88-generic/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko
license:        GPL v2
description:    Intel(R) PRO/1000 Network Driver
author:         Intel Corporation, <linux.nics@intel.com>
version:        5.15.0-88-generic
firmware:       e1000e/82574.bin
alias:          pci:v00008086d000015F9sv*sd*bc*sc*i*
depends:        ptp
retpoline:      Y
intree:         Y
name:           e1000e
vermagic:       5.15.0-88-generic SMP mod_unload modversions 
parm:           InterruptThrottleRate:Set interrupt rate (array of int)
parm:           IntMode:Change Interrupt Mode (0=legacy, 1=MSI, 2=MSI-X) (array of int)
parm:           SmartPowerDownEnable:Enable PHY smart power down (array of int)

Key modinfo Extraction Flags

• -p, --parameters: Lists only the configurable module parameters and descriptions.
• -d, --description: Prints the module description string.
• -a, --author: Prints the author information.
• -l, --license: Prints the software license type (e.g., GPL, GPL v2, Dual BSD/GPL).
• -F <field>, --field <field>: Displays only the value of the specified field (e.g., modinfo -F filename e1000e, modinfo -F depends e1000e).

5. depmod

depmod generates the modules.dep file and associated binary indexes (modules.dep.bin, modules.alias.bin, modules.symbols.bin) by analyzing all module ELF headers under /lib/modules/<version>/ for exported and unresolved symbols.

# Generate dependency files for the currently running kernel
$ sudo depmod -a

# Generate dependency files for a newly installed kernel
$ sudo depmod -a 5.19.0-45-generic

# Perform a dry run and output dependency mapping to stdout
$ depmod -n

Exam Rule: Whenever you manually copy a custom or updated .ko module file into /lib/modules/$(uname -r)/, you must run depmod -a before modprobe can recognize and load it.

5. Persistent Module Configuration: /etc/modprobe.d/*.conf

While legacy Linux systems used a single /etc/modprobe.conf file, modern distributions process modular configuration files located in /etc/modprobe.d/*.conf (all files must end with the .conf extension).

Configuration Directives

Comprehensive Configuration Example

# /etc/modprobe.d/custom-hardware.conf

# 1. Provide an alias for legacy network binding
alias eth1 r8169

# 2. Configure driver options for power management and interrupt modes
options iwlwifi power_save=1 uapsd_disable=0
options e1000e SmartPowerDownEnable=1

# 3. Blacklist problematic or conflicting open-source drivers
blacklist nouveau
blacklist pcspkr

# 4. Completely neutralize a blacklisted module by mapping its install to /bin/false
install nouveau /bin/false

Exam Trap — Blacklisting vs. Install Redirection: Adding blacklist nouveau to /etc/modprobe.d/blacklist.conf prevents udev from auto-loading nouveau when the graphics card is probed. However, if a user or script explicitly executes modprobe nouveau, the kernel will still load it. To completely prevent a module from loading under any circumstances, combine blacklisting with an install redirect:

install nouveau /bin/true
# or
install nouveau /bin/false

6. Differentiating Types of Mass Storage Devices

Objective 101.1 asks you to differentiate between various types of mass storage devices. The exam tests this through device-node naming and through which kernel driver claims the hardware — because on Linux the interface a drive speaks determines the name it gets in /dev.

Why SATA, SCSI, SAS and USB All Become /dev/sd*

The single most-tested point here is that sd does not stand for "SATA disk." It stands for SCSI disk. Linux routes SATA (through libata), true SCSI, SAS, and USB mass storage (through usb-storage) into one common SCSI block layer, so all four families receive /dev/sd? names assigned in detection order, not by physical port. Unplug a USB stick and reboot, and what was /dev/sdc may become /dev/sdb — which is exactly why /etc/fstab should use UUIDs or labels rather than device nodes.

NVMe is the exception. NVMe drives bypass the SCSI translation layer entirely and speak their own command set directly over PCIe, so they get their own namespace-aware naming scheme: /dev/nvme<controller>n<namespace>p<partition>.

Inspecting What You Actually Have

# Tree of block devices with size, type and mount point
$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 465.8G  0 disk
├─sda1        8:1    0   512M  0 part /boot/efi
└─sda2        8:2    0 465.3G  0 part /
nvme0n1     259:0    0   1.8T  0 disk
└─nvme0n1p1 259:1    0   1.8T  0 part /srv/data
sr0          11:0    1  1024M  0 rom

# Vendor, model and transport for every storage device
$ lsblk -o NAME,SIZE,TYPE,TRAN,ROTA,MODEL

# Is it spinning rust or solid state? 1 = rotational HDD, 0 = SSD/flash
$ cat /sys/block/sda/queue/rotational
0

# Full hardware report restricted to storage
$ sudo lshw -class disk -class storage

# Which controller and which driver claims it
$ lspci -k | grep -A3 -i 'sata\|nvme\|raid'

Exam Rule: Memorise three node families and what they imply. /dev/sd* = anything routed through the SCSI layer (SATA, SCSI, SAS, USB). /dev/nvme0n1p1 = NVMe, and note the mandatory p before the partition number. /dev/sr0 = optical. A question that shows /dev/vda is telling you the system is a virtual machine using VirtIO paravirtualised storage.