Understanding the Linux Root Filesystem and Boot Process

Understanding how Linux organizes its filesystem and boots up is fundamental to system administration. In this guide, we'll explore the root filesystem structure, the boot process, and the critical role of initramfs.

The Root Filesystem /

Root Filesystem Directory Structure

The Linux filesystem hierarchy is organized into several key directories, each serving a specific purpose:

Key Directories Explained

/proc - Virtual Filesystem

The /proc directory is a virtual filesystem that doesn't exist on disk. It provides a window into kernel and process information:

• /proc/cpuinfo - CPU details
• /proc/meminfo - Memory statistics
• /proc/[PID]/ - Information about running processes
• Everything here is generated on-the-fly by the kernel

/sys - Virtual Filesystem for Hardware/Driver Info

A modern alternative to some /proc functionality, providing a direct interface to the kernel device model.

/boot - Boot Loader Files

This is where the kernel lives! It contains:

• vmlinuz - The compressed Linux kernel
• initramfs - Initial RAM filesystem
• Bootloader configuration files

/etc - Editable Text Configuration

System configuration files live here:

• /etc/fstab - Filesystem mount table
• /etc/passwd - User account information
• /etc/hosts - Static hostname resolution
• Application configs

/lib and /lib64 - Shared Libraries

Essential shared libraries for /bin and /sbin:

• Like .dll files on Windows
• /lib64 contains 64-bit libraries
• Kernel modules in /lib/modules/

/usr - User Programs and Data

• /usr/bin - User commands
• /usr/lib - Libraries for /usr/bin
• /usr/share - Architecture-independent data (docs, icons)
• /usr/local - Locally installed software

/var - Variable Data

• Log files in /var/log
• Temporary files in /var/tmp
• Package manager cache
• Mail spools, databases

/dev - Device Files

• /dev/sda - Hard drives
• /dev/null - Null device
• /dev/random - Random number generator

/bin and /sbin - Essential Binaries

• /bin - Basic user commands (ls, cp, cat)
• /sbin - System administration commands (fsck, init, mount)
• Often symlinked to /usr/bin and /usr/sbin on modern systems

/home - User Home Directories

• /home/username - Individual user data and configs
• Personal documents, settings, application data

/root - Root User's Home Directory

• Separate from /home for security
• Root user's personal files and configs

/tmp - Temporary Files

• Cleared on reboot (usually)
• World-writable
• Used by applications for temporary storage

/opt - Optional/Add-on Software

• Third-party applications
• Self-contained software packages
• Example: /opt/google/chrome

/mnt and /media - Mount Points

• /mnt - Temporary mount points for sysadmins
• /media - Removable media (USB drives, CDs)
• Auto-mounted devices typically go in /media

The Root Filesystem Problem

Modern Linux systems have complex storage setups:

• LVM (Logical Volume Manager)
• RAID arrays
• Encrypted filesystems (LUKS)
• Network filesystems (NFS)

The kernel cannot natively access these complex storage schemes on the disk and needs drivers to access them. But the drivers are ON the disk itself - this is where initramfs/initrd comes in.

Initial RAM Filesystem/Disk (initramfs/initrd)

What is initramfs?

The initial RAM Filesystem is a temporary root filesystem loaded into RAM. It contains minimal tools needed to bootstrap and mount the real root filesystem.

initramfs vs Real Root: Directory Comparison

Note: /hooks and /install are build-time only (Arch-specific) - used by mkinitcpio to build initramfs, not present in the final image.

How initramfs Works

1. BIOS/UEFI loads bootloader (GRUB)
2. GRUB loads vmlinuz (kernel) + initramfs into RAM
3. Kernel decompresses itself, starts execution
4. Kernel extracts initramfs as temporary root (/)
5. Kernel runs /init script from initramfs
6. /init script:
   • Mounts /proc, /sys, /run
   • Starts udev for device detection
   • Loads necessary kernel modules (disk controllers, filesystems, etc.)
   • Assembles RAID/LVM if needed
   • Unlocks encrypted volumes if needed (prompts for password)
   • Finds and mounts real root filesystem (usually to /new_root or /mnt)
   • Runs fsck on real root if needed
7. switch_root: Transitions from initramfs to real root
8. Starts /sbin/init (systemd) on real root
9. Normal boot continues (user sessions, services, etc.)

Rebuild initramfs

After kernel or driver changes, rebuild initramfs:

sudo mkinitcpio -P  # Rebuild all presets

initramfs vs initrd (Historical)

initramfs is the modern replacement for the older initrd:

Typical initramfs Contents (Arch Linux)

View the contents of your initramfs:

lsinitcpio /boot/initramfs-linux.img

Kernel Modules Included

• Disk Controllers: ahci, nvme, ata_piix, virtio_blk
• Filesystems: ext4, btrfs, xfs, fat, vfat
• Device Mapper: dm-mod, dm-crypt (for encryption)
• MD RAID: md-mod, raid0, raid1, etc.
• USB/Input: If booting from USB or needing keyboard in emergency

Binaries Included (via busybox or individual)

• mount, umount - Mounting filesystems
• modprobe, insmod - Loading kernel modules
• sh, bash - Shell for init script
• switch_root - Transitioning to real root
• udevd, udevadm - Device management
• cryptsetup - If using LUKS encryption
• lvm - If using LVM
• fsck utilities - Filesystem checking

initramfs Generation (Arch Linux)

On Arch, mkinitcpio generates initramfs based on /etc/mkinitcpio.conf:

# /etc/mkinitcpio.conf
MODULES=()  # Kernel modules to include
BINARIES=() # Extra binaries to include
FILES=()    # Extra files to include
HOOKS=(base udev autodetect modconf block filesystems keyboard fsck)

Common Hooks and What They Add

• base - Basic initramfs structure, busybox
• udev - udev for device management
• autodetect - Detect hardware, include only needed modules
• modconf - Module configuration from /etc/modprobe.d/
• block - Block device support
• filesystems - Filesystem drivers
• keyboard - Keyboard support for emergency shell
• encrypt - LUKS encryption support
• lvm2 - LVM support
• resume - Hibernation resume support

Size Comparison

# Compare initramfs sizes
ls -lh /boot/initramfs-*
# Typical sizes:
# initramfs-linux.img:          ~15-30 MB (optimized for your hardware)
# initramfs-linux-fallback.img: ~100-200 MB (all possible drivers)

The fallback is much larger because it includes drivers for all hardware, not just yours.

CPIO: Copy In and Out

CPIO is an archive format (like tar or zip) that bundles multiple files into one file. It's built into the Linux kernel - that's why initramfs uses it!

# Create archive
find . | cpio -o > archive.cpio
# Extract archive
cpio -idmv < archive.cpio

initramfs Structure

Two Layers

initramfs-linux.img │ └─> Compressed (gzip/xz/zstd) ← Outer layer │ └─> cpio archive ← Inner layer │ └─> Actual files (init, bin/, lib/, etc.)

Why Two Layers?

• cpio = packages files together
• compression = makes it smaller
• Kernel only needs to understand cpio
• Bootloader handles decompression

Extracting initramfs

zcat /boot/initramfs-linux.img | cpio -idmv

What This Does

1. zcat → decompress the file
2. cpio -idmv → extract the archive

Thus: initramfs = compressed cpio archive

Extracting and Exploring initramfs

# Create directory for extraction
mkdir -p /tmp/initramfs-explore
cd /tmp/initramfs-explore
# Extract (initramfs is usually a gzipped cpio archive)
lsinitcpio -x /boot/initramfs-linux.img
# Or manually:
zcat /boot/initramfs-linux.img | cpio -idmv
# Explore the structure
ls -la
tree -L 2  # If tree is installed
# View the init script
cat init
# See what modules are included
ls -la usr/lib/modules/*/kernel/

The Kernel - vmlinuz (Virtual Memory Linux Zipped)

vmlinuz ├─> Boot Header/Setup Code ← Small (few KB) │ (Real mode code, boot protocol) ├─> Compressed Kernel ← Largest part (8-15 MB) │ (The actual kernel code, compressed) └─> Decompression Code ← Small (few KB) (Self-extracting stub)

Kernel Structure

1. Boot Header (Front) - First ~512 bytes (or more)

• Contains boot protocol information
• Makes kernel bootable
• Tells bootloader how to load the kernel
• Real-mode (16-bit) setup code

2. Decompression Stub

• Small piece of code (written in assembly/C)
• Runs before the main kernel
• Self-extracting: decompresses the kernel
• Minimal, doesn't need external tools

3. Compressed Core Kernel Components

The actual kernel code, compressed with:

Modern kernels typically use xz or zstd.

1. Kernel Code

• Process scheduler
• Memory management (virtual memory, paging)
• System call interface
• Interrupt handling
• Core subsystems (VFS, networking stack, etc.)

2. Built-in Drivers

• Essential device drivers compiled into the kernel
• Not loadable modules
• Example: console drivers, basic disk support

3. Kernel Data Structures

• System tables
• Default configuration
• Built-in firmware (sometimes)

4. Init Code

• Initialization routines
• Hardware detection code
• Module loading framework

Kernel Compilation / Build Process: vmlinux → vmlinuz

Kernel Source Code ↓ Compilation ↓ vmlinux (uncompressed ELF, ~30-50 MB) ↓ Strip symbols (optional) ↓ Compress (gzip/xz/zstd) ↓ Add boot header & decompression stub ↓ vmlinuz / bzImage (bootable, ~8-15 MB)

Notes

What's NOT in vmlinuz

• Kernel modules (*.ko files) → in /usr/lib/modules/
• initramfs → separate file /boot/initramfs-*
• Bootloader (GRUB, systemd-boot) → separate files
• User-space programs → on root filesystem

Terminology

vmlinux = Raw, uncompressed kernel ELF file (~30-50MB)

• Created during kernel compilation
• Not directly bootable
• Contains debug symbols (if built with them)

vmlinuz = Bootable, compressed kernel image (~8-15MB)

• What you actually boot
• Self-decompressing
• Contains boot header

bzImage = "big zImage" (historical name)

• Another name for vmlinuz
• Name from build process (make bzImage)

What Happens During make bzImage

# Kernel build creates:
arch/x86/boot/bzImage → copied to /boot/vmlinuz-<version>
# The build process:
# 1. Compile kernel → vmlinux
# 2. Compress vmlinux → vmlinux.bin.gz (or .xz, .zst)
# 3. Combine: boot_header + decompress_stub + vmlinux.bin.gz
# 4. Output: bzImage (bootable)

dmesg (Diagnostic Messages / Display Message)

dmesg is a command that shows kernel messages from boot until now. The kernel has a ring buffer (circular buffer) in RAM where it logs messages: Kernel Ring Buffer (in RAM) ├─ Boot messages ├─ Hardware detection ├─ Driver loading ├─ Errors/warnings └─ Current events

# Basic usage
dmesg

# Options:
# -T: human readable format
# -w: watch (like tail -f)
# --level=[err|warn|...]

# Search for something
dmesg | grep -i usb

Boot Process

The Bootloader

The bootloader is the first software that runs when you turn on your computer. Its job is to:

1. Load the kernel (vmlinuz) into RAM
2. Load initramfs into RAM
3. Tell the kernel where to find the root filesystem
4. Hand control over to the kernel ┌─────────────────┐ │ Your System │ └────────┬────────┘ │ ┌────▼─────┐ │ Firmware │ ← BIOS or UEFI (in motherboard) 4-10s └────┬─────┘ │ ┌────▼────────┐ │ Bootloader │ ← Bootloader of choice 0.5-2s └────┬────────┘ │ ┌────▼─────┐ │ Kernel │ ← vmlinuz 1-3s └──────────┘ │ ┌────▼─────┐ │ Userspace│ ← systemd starting service, network manager,... 2-10s └──────────┘

Bootloaders

Check currently used bootloader:

bootctl status

GRUB (GRand Unified Bootloader)

• Most popular on Linux
• Two versions: GRUB Legacy (old) and GRUB 2 (current)
• Works with both BIOS and UEFI
• Config: /boot/grub/grub.cfg

systemd-boot (formerly gummiboot)

• Simpler, minimal
• UEFI-only (doesn't work with BIOS)
• Popular on Arch, Fedora
• Config: /boot/loader/loader.conf

rEFInd

• Graphical boot menu
• UEFI-only
• Good for dual-boot

Firmware - BIOS/UEFI

The firmware on the motherboard loads the bootloader.

BIOS - Basic Input/Output System

BIOS Boot Process: Disk (MBR - Master Boot Record first 512B of the Disk) └── First 440 bytes = GRUB stage 1 └── MBR gap or separate /boot partition = GRUB stage 1.5 & 2

UEFI - Unified Extensible Firmware Interface

UEFI Boot Process: ESP (EFI System Partition) └── /boot/EFI/ ├── BOOT/ │ └── BOOTX64.EFI ← Default fallback ├── grub/ │ └── grubx64.efi ← GRUB for UEFI └── systemd/ └── systemd-bootx64.efi ← systemd-boot

Check if UEFI:

ls /sys/firmware/efi # if not empty -> UEFI

Step-by-Step Boot Process

UEFI/BIOS loads bootloader (EFI/BOOT/bootx64.efi or GRUB from EFI/) ↓ Bootloader (GRUB/systemd-boot) loads vmlinuz into RAM │ GRUB Menu (grub/grub.cfg) ├─> Option 1: Arch Linux (Standard Kernel) │ ├─ Load: intel-ucode.img │ ├─ Load: vmlinuz-linux │ └─ Load: initramfs-linux.img → Temporary Root FS │ └─> Mount real / → Real Root FS └─> Option 2: Arch Linux LTS ├─ Load: intel-ucode.img ├─ Load: vmlinuz-linux-lts └─ Load: initramfs-linux-lts.img → Temporary Root FS └─> Mount real / → Real Root FS ↓ Bootloader also loads initramfs into RAM ↓ Bootloader transfers control to vmlinuz boot header ↓ Boot header setup code runs (real mode → protected mode) ↓ Decompression stub executes ↓ Kernel decompresses itself in RAM ↓ Decompressed kernel starts execution ↓ Kernel initializes hardware, mounts initramfs ↓ Kernel executes /init from initramfs ↓ initramfs mounts real root, switches to it ↓ System continues booting...

View your boot files:

ls -la /boot

File Breakdown

Kernels (vmlinuz)

• vmlinuz-linux - Standard Arch Linux kernel
• vmlinuz-linux-lts - Long Term Support kernel (older, more stable)

initramfs Images (The Temporary Root Filesystems!)

Standard Kernel Images:

• initramfs-linux.img - Normal initramfs for standard kernel
  • Contains drivers for your specific hardware
  • Generated by mkinitcpio based on /etc/mkinitcpio.conf
• initramfs-linux-fallback.img - Fallback initramfs for standard kernel
  • Contains ALL possible drivers (much larger)
  • Use this if normal initramfs fails to boot
  • Slower boot but more compatible

LTS Kernel Images:

• initramfs-linux-lts.img - Normal initramfs for LTS kernel
• initramfs-linux-lts-fallback.img - Fallback for LTS kernel

CPU Microcode

• intel-ucode.img - Intel CPU microcode updates
  • Loaded before kernel to patch CPU bugs/vulnerabilities
  • AMD users would have amd-ucode.img

Bootloader Files

• EFI/ - UEFI boot files
• grub/ - GRUB bootloader configuration and modules
• loader/ - systemd-boot configuration (if using systemd-boot)
• FSCK0000.REC - Recovered filesystem check data (ignore/delete if old)

Benchmarking Your Boot Process

# Overall boot time breakdown
systemd-analyze

# See what took time during boot
systemd-analyze blame

# Visual timeline (opens SVG in browser)
systemd-analyze plot > boot.svg

# Critical path (what delayed boot the most)
systemd-analyze critical-chain

Understanding the Linux filesystem hierarchy and boot process is essential for effective system administration. From the firmware loading the bootloader, to the kernel decompressing itself, to initramfs preparing the real root filesystem - each step plays a crucial role in getting your system up and running.