2.4 Kernel Initialization, Initramfs & System Logs (101.2)

2.4 Kernel Initialization, Initramfs & System Logs

Quick Summary: Once loaded by the bootloader, the compressed kernel (vmlinuz) initializes core hardware and unpacks the initramfs (Initial RAM Filesystem). The initramfs provides a temporary root environment containing storage, filesystem, and encryption drivers required to locate and mount the real root filesystem (/). Administrators pass boot options to the kernel via command-line arguments (visible in /proc/cmdline), troubleshoot early boot errors using dmesg to view the kernel ring buffer, and analyze system event histories using journalctl and /var/log/.

1. Kernel Decompression & Early Initialization

The Linux kernel file in /boot is named vmlinuz-<version>. The leading v stands for "virtual memory," and the trailing z indicates that the kernel binary is compressed (using gzip, xz, or zstd).

Kernel Boot Sequence

1. Self-Decompression: The bootloader loads vmlinuz into physical RAM. A small embedded decompressor program uncompresses the kernel code into high memory and jumps to the kernel entry point.
2. CPU Mode Setup: The kernel switches the processor from real mode/32-bit mode into 64-bit long mode with paging enabled.
3. Hardware Subsystem Probing: The kernel parses ACPI tables, probes system timers, detects available RAM, and initializes CPU symmetric multiprocessing (SMP).
4. Initramfs Extraction: The kernel creates a tmpfs RAM filesystem in memory and extracts the initial ramdisk archive (initramfs) into it.
5. Executing /init: The kernel spawns its first user-space process inside the RAM disk: /init.

2. Initramfs vs. Initrd: The Root Mounting Problem

The Problem It Solves

A modern Linux installation frequently places the root filesystem on complex storage configurations:

• Hardware RAID or Software RAID (mdadm)
• Logical Volume Manager (LVM)
• NVMe or multipath SAN storage
• LUKS full-disk encryption (cryptsetup)
• Network storage (iSCSI or NFS)

If the drivers for these storage layers were compiled as loadable kernel modules (.ko), the kernel could not load them because they reside in /lib/modules/ on the very root filesystem the kernel cannot yet read. Compiling every conceivable driver statically into the kernel would produce an enormous, inefficient binary.

The Solution: Initramfs

The initramfs is a compressed cpio archive containing a minimal user-space root environment (busybox/systemd utilities, required .ko kernel modules, and initialization scripts).

[Bootloader] ──► Loads vmlinuz + initramfs into RAM
                      │
                      ▼
[Kernel] ──────► Mounts tmpfs in RAM & unpacks initramfs cpio archive
                      │
                      ▼
[/init Script] ─► 1. Load NVMe / LVM / RAID / LUKS modules
                  2. Unlock encrypted volume (prompt password)
                  3. Scan LVM volume groups (vgscan / vgchange)
                  4. Mount real root disk read-only at /sysroot
                  5. Execute switch_root /sysroot /sbin/init
                      │
                      ▼
[Real System] ──► systemd takes over PID 1 on real root filesystem (/)

Generating the Initramfs Image

• Red Hat / Fedora / SUSE: dracut (modern) or legacy mkinitrd

  # Rebuild initramfs for current kernel
  sudo dracut -f
  
  # Rebuild initramfs for a specific kernel version
  sudo dracut -f /boot/initramfs-5.15.0-88-generic.img 5.15.0-88-generic
  

• Debian / Ubuntu: update-initramfs or mkinitramfs

  # Update the initramfs for the currently running kernel
  sudo update-initramfs -u
  
  # Generate initramfs for all installed kernels
  sudo update-initramfs -c -k all
  

3. Kernel Command-Line Parameters

Kernel parameters (also called boot arguments) are strings passed from the bootloader (GRUB 2) to the kernel at boot. The active parameters for the running system are stored in plaintext in /proc/cmdline.

$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-5.15.0-88-generic root=UUID=c3a4d5e6-7890-4abc-9def-1234567890ab ro quiet splash systemd.unit=multi-user.target

Essential Kernel Parameters for LPIC-1

4. Inspecting the Kernel Ring Buffer: dmesg

During early boot, before logging daemons (rsyslogd or systemd-journald) have started, the kernel stores all system log messages, hardware probe results, and driver errors in an internal memory structure called the Kernel Ring Buffer.

Characteristics of the Ring Buffer

• Stored in kernel RAM; fixed size (e.g., 512 KiB to 8 MiB).
• As new messages arrive after the buffer fills, the oldest messages are overwritten (circular FIFO).
• Accessible via the device node /dev/kmsg or the /proc/kmsg interface.

The dmesg Command

dmesg dumps the contents of the kernel ring buffer to standard output.

# Standard dmesg snippet
$ dmesg
[    0.000000] Linux version 5.15.0-88-generic (buildd@lcy02) ...
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.15.0-88-generic root=UUID=... ro quiet
[    1.245892] e1000e: Intel(R) PRO/1000 Network Driver
[    1.245910] e1000e 0000:00:1f.6 eth0: (PCI Express:2.5GT/s:Width x1) 00:15:5d:01:23:45
[    2.102319] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)

Crucial dmesg Command-Line Flags

• -T, --ctime: Converts monotonic timestamps (seconds since boot like [ 1.245892]) into human-readable real-world date and time strings (e.g., [Sat Aug 29 19:30:15 2026]).
• -l <level>, --level=<level>: Filters messages by comma-separated severity levels:
  • emerg (0), alert (1), crit (2), err (3), warn (4), notice (5), info (6), debug (7).

  # Display only critical and error messages
  dmesg -l err,crit
  

• -w, --follow: Waits for and displays new kernel messages in real time (similar to tail -f).
• -c: Prints the ring buffer contents and then immediately clears the buffer.
• -C: Clears the ring buffer without printing (requires root privileges).
• -H, --human: Enables human-readable output with auto-paging, colorization, and relative time deltas.

5. System Log Files & journalctl

Once the operating system is booted, kernel messages and user-space service events are captured by system loggers.

Traditional Log Files in /var/log/

• /var/log/dmesg (or /var/log/boot.log): Snapshot of the kernel ring buffer captured during the boot sequence.
• /var/log/messages: General system activity log used by RHEL, CentOS, and SUSE.
• /var/log/syslog: General system activity log used by Debian and Ubuntu.
• /var/log/kern.log: Dedicated kernel message log in Debian/Ubuntu systems.

Querying Boot Logs with journalctl

On systemd-based systems, systemd-journald captures binary log streams from the kernel, stdout/stderr of services, and syslog calls.

# Display only kernel messages (equivalent to dmesg)
$ journalctl -k
# or
$ journalctl --dmesg

# View logs from the current boot session
$ journalctl -b

# View logs from the previous boot session (requires persistent /var/log/journal)
$ journalctl -b -1

# View logs from two boots ago
$ journalctl -b -2

# Filter logs by priority level (err and above)
$ journalctl -p err -b

# Follow logs continuously in real time
$ journalctl -f

6. The Three Init Systems LPI Expects You to Recognise

Objective 101.2 asks for knowledge of SysVinit and systemd and explicit awareness of Upstart. Upstart is the one most candidates skip, and it is the one the exam is most likely to use as a distractor, because it briefly shipped as the default on Ubuntu 6.10–14.10 and on Red Hat Enterprise Linux 6.

Upstart was Canonical's event-driven replacement for SysVinit. Instead of walking a fixed sequence of numbered rc scripts, Upstart reacted to events — "filesystem mounted", "network interface came up", "another job started" — and launched jobs whose conditions those events satisfied. That made boot parallel and made service start-up ordering implicit rather than hand-numbered.

Upstart job files live in /etc/init/ — note that this is a different directory from SysVinit's /etc/init.d/, and telling those two paths apart is a classic single-character exam trap. A minimal Upstart job looked like this:

# /etc/init/myapp.conf
description "Example application"
start on runlevel [2345]
stop on runlevel [016]
respawn
exec /usr/local/bin/myapp

The initctl command was Upstart's equivalent of systemctl:

# List all known Upstart jobs and their goal/state
initctl list

# Query one job
initctl status myapp

# Start and stop jobs
start myapp
stop myapp

Exam Rule: LPI only requires awareness of Upstart — you will not be asked to author a job file. Be able to (a) name it as the event-driven init system that sat between SysVinit and systemd, (b) place its job files in /etc/init/, and (c) recognise initctl as its control command. Every current mainstream distribution has since migrated to systemd; Upstart is effectively dead outside legacy RHEL 6 and old Ubuntu LTS installs.