LPIC-1 System Architecture: Hardware Discovery and the Boot Sequence

Beginner30 min7 steps

What you'll learn

Discover what hardware is present with lspci, lsusb, lsblk, and lscpu
Find which kernel driver (module) is bound to a device using lspci -k and lsmod
Tell /sys, /proc, and /dev apart and say what udev does
Recite the boot sequence in order: firmware to GRUB 2 to kernel + initramfs to systemd
Explain what the initramfs is for and why the root filesystem can't mount without it

Why architecture before everything else
Frame the exam topic: you can't fix what you can't see, and nothing runs until the machine boots.
Before you can manage a Linux box you have to answer two questions the machine answers for itself every time it powers on:
- What hardware is here, and is the kernel actually talking to it?
- How did this thing get from a cold chip to a login prompt?
These are the two halves of LPIC-1 "System Architecture," and they're the same skill seen from two angles. Hardware discovery is reading the kernel's inventory of devices. The boot sequence is the story of how that inventory got built — each stage handing off to the next until the system is alive.
Think of a new machine like a building on its first day. Hardware discovery is walking the floors with a clipboard, noting every room and what's wired to it. The boot sequence is the morning startup checklist: unlock the front door, turn on the power, bring up the lights, then open for business. Skip a step and nobody gets in.
Why it matters
Real troubleshooting starts here. "The network card isn't working" almost always means the device is present but no driver is bound to it, or the boot stopped before the driver loaded. If you can't read the hardware inventory and can't name the boot stages, every hardware bug looks like magic. This lesson makes both legible.
Take the hardware inventory
List the devices on the system with the four core ls* discovery tools.
Four commands cover the hardware an exam (and a real outage) cares about. Each reads a different bus or subsystem:
- lspci — devices on the PCI bus: network cards, GPUs, storage controllers
- lsusb — devices on the USB bus: keyboards, drives, dongles
- lsblk — block devices: disks and their partitions, as a tree
- lscpu — the CPU: cores, architecture, virtualization flags
Start with the PCI bus, where most of the interesting permanently-attached hardware lives.
Example — not runnable on your lab box
```
$ lspci
```
```
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:02.0 VGA compatible controller: Cirrus Logic GD 5446
00:03.0 Ethernet controller: Red Hat, Inc. Virtio network device
00:04.0 SCSI storage controller: Red Hat, Inc. Virtio block device
```
Each line is one PCI device: the bus address (00:03.0), the class (Ethernet controller), and the vendor/model. This is the kernel telling you what's physically wired to the PCI bus. Notice line 00:03.0 — that's our network card. We'll come back to it to ask the crucial follow-up: which driver is driving it?
```
$ lsblk
```
```
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda      8:0    0   20G  0 disk
├─sda1   8:1    0    1G  0 part /boot
└─sda2   8:2    0   19G  0 part /
```
(tree)
lsblk indents partitions under their disk so you see the whole storage layout at a glance.
sda is a 20G disk; sda1 and sda2 are its partitions, shown nested beneath it. The MOUNTPOINTS column ties storage to the filesystem: sda1 is /boot (where the kernel and initramfs live) and sda2 is / (the real root). Remember those two — they're exactly what the boot sequence has to reach.
```
$ lscpu | head
```
```
Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
CPU(s):                  4
Vendor ID:               GenuineIntel
Model name:              Intel Xeon (Skylake)
Virtualization:          VT-x
```
lscpu summarizes the processor: architecture (x86_64), core count (CPU(s): 4), and capability flags. The Virtualization: VT-x line tells you the CPU can run hardware-accelerated VMs — the kind of detail you check before deploying virtualization. lsusb (not shown) does the same job for the USB bus.
Check yourself
You need a tree view of all disks and their partitions with mount points. Which of the four discovery commands do you reach for?
Which driver is bound? lspci -k + lsmod
Move from 'the device exists' to 'the kernel has a working driver for it' — the real diagnostic.
A device showing up in lspci only proves it's physically present. It does not prove the kernel can use it. The kernel talks to hardware through a driver, which is usually a loadable kernel module. The diagnostic question is always: is a driver bound to this device, and is that module actually loaded?
Add -k to lspci to print the kernel driver in use for each device.
```
$ lspci -k | head
```
```
00:03.0 Ethernet controller: Red Hat, Inc. Virtio network device
	Subsystem: Red Hat, Inc. Device 0001
	Kernel driver in use: virtio-pci
	Kernel modules: virtio_pci
00:04.0 SCSI storage controller: Red Hat, Inc. Virtio block device
	Kernel driver in use: virtio-pci
```
-k
Show the kernel driver currently bound to each device, plus the modules that can drive it.
Now the Ethernet card has two extra lines. `Kernel driver in use: virtio-pci` is the headline — a driver is bound, so the card works. `Kernel modules: virtio_pci` lists modules capable of driving it. If Kernel driver in use were missing for a device, that's your bug: the hardware is there but nothing is driving it.
lspci -k named the module. lsmod confirms that module is actually loaded into the running kernel and shows what depends on it.
```
$ lsmod | head
```
```
Module                  Size  Used by
virtio_net             57344  0
virtio_pci             28672  0
virtio_blk             20480  3
ext4                  942080  1
```
Each row is a loaded module: its name, memory size, and the Used by count — how many other things depend on it. virtio_pci appears here, confirming the driver lspci -k named is genuinely loaded. If you suspect a driver problem, this is how you check: lsmod | grep <module>. Nothing back means the module isn't loaded, which is why the device is silent.
"It shows in lspci, so it must work"
The classic trap. lspci listing a device only means it's plugged in and detected on the bus — not that it's usable. A network card with no `Kernel driver in use` line is present but dead. Always take the second step: lspci -k for the binding, lsmod for the module. Detection and a working driver are two different things.
Check yourself
Which single flag added to lspci reveals the kernel driver currently bound to each device?
The pseudo-filesystems: /sys, /proc, /dev
Tell the three kernel-backed directories apart and say what udev does with /dev.
Those ls* tools don't have magic hardware knowledge — they read it from pseudo-filesystems: directories that aren't files on a disk but live windows the kernel paints in memory. Three matter for LPIC-1, and confusing them is a common exam slip:
- `/sys` — the device model. The kernel's structured map of every device, bus, and driver. lspci -k and udev read here.
- `/proc` — kernel and process info. One numbered directory per running process (/proc/1234/), plus kernel knobs like /proc/cpuinfo.
- `/dev` — the device nodes programs actually open: /dev/sda, /dev/null. These special files are created and named by udev.
Analogy: /sys is the building's wiring blueprint (every circuit mapped), /proc is the live activity log (who's in which room right now), and /dev is the wall of labeled outlets you plug into. udev is the electrician who reads the blueprint in /sys and installs the right labeled outlet in /dev the moment a device appears.
```
$ ls /sys/class/net
```
```
eth0  lo
```
/sys/class/net groups every network interface the kernel knows about. eth0 is the card we traced through lspci; lo is the loopback. Because /sys is the kernel's own device model, this list is authoritative — it's exactly what udev consulted to create the matching device entries.
Note
Mnemonic: /sys = devices, /proc = processes (and kernel), /dev = the nodes you open. When you cat /proc/cpuinfo, you're not reading a file on disk — the kernel generates that text on the spot. That's the whole idea of a pseudo-filesystem: a directory that's really a conversation with the kernel.
Check yourself
Which pseudo-filesystem holds one numbered directory per running process, like /proc/1234?
The boot sequence, in order
Recite the four hand-offs from power-on to PID 1 and know who reads what.
Now the second half: how the machine got from cold silicon to that hardware-rich, running system. Boot is a relay race — each runner does one leg and hands the baton to the next. Memorize the order; LPIC-1 tests it directly.
1. Firmware. The motherboard's built-in code runs first. Two flavors:
- BIOS (legacy): reads the MBR — the first 512 bytes of the boot disk — to find a bootloader.
- UEFI (modern): reads the ESP (EFI System Partition), a small FAT partition holding bootloader .efi files.
2. GRUB 2. The bootloader the firmware loads. It presents the boot menu and loads the kernel plus the initramfs into memory.
3. Kernel + initramfs. The kernel starts and uses the initramfs (next step explains why) to mount the real root filesystem.
4. systemd. The kernel hands off to the first user-space process, PID 1 — on modern Linux that's systemd, which brings up every service to a usable system.
```
$ ls /boot
```
```
config-6.5.0-1   grub2   initramfs-6.5.0-1.img   vmlinuz-6.5.0-1
```
The boot sequence made flesh, all on the /boot partition (sda1 from earlier). vmlinuz-* is the compressed kernel, initramfs-*.img is the initramfs GRUB loads alongside it, and grub2/ holds GRUB 2's config. The firmware found GRUB, GRUB found these two files, and together they reached the root filesystem.
BIOS/MBR vs. UEFI/ESP — don't cross the wires
The single most common architecture mix-up. BIOS pairs with the MBR (512 bytes at the very start of the disk). UEFI pairs with the ESP (a real FAT partition full of .efi files). Saying "UEFI reads the MBR" or "BIOS boots from the ESP" is wrong and is a classic distractor on the exam. Keep the pairs together: BIOS→MBR, UEFI→ESP.
Check yourself
What is the name of the very first user-space process (PID 1) that the kernel hands off to on a modern Linux system?
What the initramfs is for
Explain the chicken-and-egg the initramfs solves: you need a driver to read the disk that holds the driver.
Step 3 glossed over a real puzzle. To mount the root filesystem the kernel needs a driver for whatever holds it — a SATA controller, an NVMe drive, an LVM or RAID layer, maybe an encrypted volume. But that driver is itself a module stored on the root filesystem.
So: to read the disk, you need the driver — and the driver lives on the disk you can't read yet. A perfect chicken-and-egg.
Analogy: the key to the toolshed is locked inside the toolshed. The initramfs is the spare key taped under the doormat. It's a tiny, self-contained root filesystem GRUB loads into RAM next to the kernel, and it carries exactly the drivers needed to reach the real root. The kernel mounts the initramfs first (it's already in memory, no driver required), loads the storage driver from it, and now it can mount the real root filesystem and pivot to it.
Example — not runnable on your lab box
```
$ lsinitrd /boot/initramfs-6.5.0-1.img | grep -i virtio | head
```
```
drwxr-xr-x   2 root  root  ... usr/lib/modules/6.5.0-1/kernel/drivers/block/virtio_blk.ko
-rw-r--r--   1 root  root  ... usr/lib/modules/6.5.0-1/kernel/drivers/net/virtio_net.ko
```
lsinitrd lists what's packed inside the initramfs image. There they are: the storage driver virtio_blk.ko and friends, bundled in so the kernel can mount our virtio disk before the real root is available. The spare key is taped under the mat exactly as promised — these are the modules that break the chicken-and-egg.
"The kernel can just mount root by itself"
Only if the storage driver is compiled directly into the kernel (built-in, not a module). The moment your root sits on hardware whose driver is a module — or on LVM, RAID, or an encrypted disk — the kernel cannot reach root without the initramfs. A broken or missing initramfs is a leading cause of "kernel panic - unable to mount root." Don't assume the kernel is self-sufficient; on real systems it leans on the initramfs.
Check yourself
In one or two words, what does the initramfs carry that lets the kernel mount the real root filesystem?
Try it in your live terminal
Run the read-only discovery commands yourself on the real sandbox to your right.
You have a real shell. Every command below is read-only — it inspects, it changes nothing. Run them in order and connect each to the lesson: device, then its driver, then the kernel's own view.
```
$ lspci -k | head
```
Devices on the PCI bus with their bound kernel driver. For each one, find the Kernel driver in use line — that's the difference between detected and working.
```
$ lsblk
```
Your disks and partitions as a tree. Spot which partition is /boot and which is / — the two the boot sequence has to reach.
```
$ lscpu | head
```
The processor summary: architecture, core count, virtualization support.
```
$ lsmod | head
```
The modules loaded into the running kernel. Cross-check a driver name from lspci -k to confirm it's actually loaded.
```
$ ls /sys/class/net
```
The kernel's authoritative list of network interfaces, read straight from the /sys device model — the same source udev used to build /dev.

Recap

Detection is not a working driver. lspci/lsusb/lsblk/lscpu find hardware; lspci -k plus lsmod prove a driver/module is bound and loaded.
Three pseudo-filesystems, three jobs: /sys is the device model, /proc is kernel/process info, /dev holds the nodes udev creates.
The boot relay is fixed: firmware (BIOS→MBR or UEFI→ESP) → GRUB 2 → kernel + initramfs → systemd (PID 1). Keep BIOS/MBR and UEFI/ESP paired.
The initramfs exists to break a chicken-and-egg: it carries the drivers needed to mount the real root filesystem, which would otherwise hold those very drivers.

Boot stage → what it does
Stage	What runs	What it does
1. Firmware	BIOS or UEFI	BIOS reads the MBR; UEFI reads the ESP — to find a bootloader
2. Bootloader	GRUB 2	Shows the menu; loads the kernel + initramfs into RAM
3. Kernel + initramfs	vmlinuz + initramfs.img	Kernel uses the initramfs's drivers to mount the real root filesystem
4. Init	systemd (PID 1)	First user-space process; starts all services to a usable system

LPIC-1 System Architecture: Hardware Discovery and the Boot Sequence

Why architecture before everything else

Take the hardware inventory

Which driver is bound? lspci -k + lsmod

The pseudo-filesystems: /sys, /proc, /dev

The boot sequence, in order

What the initramfs is for

Try it in your live terminal