Loading...

VONDS ©

Lab 5: Investigate the System Boot Process

Back to Lab Index

Investigate a slow-boot complaint by validating the boot device layout, inspecting kernel artifacts in /boot, reading kernel boot parameters, and identifying the init system via symlink inspection. Capture evidence using CLI-only commands suitable for documentation or escalation.

boot troubleshooting core

Scenario

Your client suspects their system takes too long to boot. You have been asked to investigate the boot sequence, identify the boot-relevant filesystem layout, locate kernel artifacts, read boot parameters, and confirm the init system in use.

Operator context

This is baseline evidence you collect before deeper timing analysis or service-level root cause work. The goal here is to confirm what the system is booting, where it is booting from, what kernel arguments are in effect, and what init process takes over.

Objective

  • Confirm block devices and mount points for boot paths.
  • Inspect kernel and initrd artifacts under /boot.
  • Read the kernel boot parameters from /proc.
  • Capture file metadata for the active kernel image.
  • Identify the init system via the /sbin/init symlink.

Concepts

  • Start with layout: if you do not understand the boot and root devices, the rest of the evidence is harder to interpret.
  • /boot holds the artifacts the bootloader loads (kernel image and initramfs). Multiple kernels can exist side-by-side.
  • /proc/cmdline shows the kernel arguments in effect for the current boot. Treat it as the source of truth for runtime boot flags.
  • Init identity matters: the init system determines service ordering, logging, and how boot timing is measured.

Walkthrough

Step 1: Show block devices and mount points.
Command 
lsblk

This confirms whether /boot is a separate partition and which device backs the root filesystem. It is your starting point for identifying the storage path the system boots from. 

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0   40G  0 disk
├─sda1   8:1    0  512M  0 part /boot
└─sda2   8:2    0 39.5G  0 part /
Step 2: List files under /boot.
Command 
ls /boot

This confirms the presence of the kernel image (vmlinuz) and initramfs (initrd.img) that the bootloader loads. It also makes it easy to spot multiple installed kernels. 

config-5.15.0-91-generic
initrd.img-5.15.0-91-generic
vmlinuz-5.15.0-91-generic
Step 3: Show kernel boot parameters.
Command 
cat /proc/cmdline

This shows the exact arguments passed to the kernel at boot, including the selected kernel image, root device, and common flags such as ro, quiet, and splash. 

BOOT_IMAGE=/boot/vmlinuz-5.15.0-91-generic root=/dev/sda2 ro quiet splash
Step 4: Capture metadata for the kernel image.
Command 
stat /boot/vmlinuz*

This captures file size and timestamps for the kernel image. It is useful evidence when you need to establish when a kernel was installed or last changed. 

File: /boot/vmlinuz-5.15.0-91-generic
Size: 11894272
Access: 2025-07-01 09:14:22.000000000
Modify: 2025-06-30 22:51:03.000000000
Change: 2025-06-30 22:51:03.000000000
Step 5: Identify the init system via symlink.
Command 
ls -l /sbin/init

On many systems, /sbin/init is a symlink to the real init binary. Following the link is a fast way to confirm whether the host is running systemd or another init system. 

lrwxrwxrwx 1 root root 20 Jan  1 00:00 /sbin/init -> /lib/systemd/systemd

Common breakpoints

/boot does not exist or is empty

Some systems use a different layout (for example, a unified kernel image, a mounted EFI system partition, or a bootloader that references paths under /boot/efi). Confirm mounts with lsblk and findmnt /boot /boot/efi.

Multiple kernels under /boot

That is normal on many systems. Use uname -r to confirm the running kernel version and correlate it with the kernel image names under /boot.

BOOT_IMAGE does not show a /boot path

The value can vary by distro and bootloader configuration. Treat it as one signal, then corroborate with uname -r and the files present under /boot.

/sbin/init is not a symlink

Some distros ship /sbin/init as a real binary or a wrapper. If it is a file, use file /sbin/init and readlink -f /sbin/init to confirm what it resolves to.

Cleanup checklist

Nothing to revert

This lab is read-only. Cleanup is saving your captured output (commands and evidence) into your notes or ticket for future comparison.

Success signal

You can quickly describe the boot storage layout, identify the kernel artifacts in use, read the active kernel arguments, and confirm the init system without relying on a GUI.

Reference

  • lsblk: Lists block devices and their mount points.
  • ls /boot: Lists boot-related files (kernel images, initramfs, configs).
    • /boot: Common location for kernel and initramfs artifacts.
  • cat /proc/cmdline: Shows the kernel boot parameters for the current boot.
    • /proc: Virtual filesystem exposing process and kernel interfaces.
    • root=: Indicates the device used as the root filesystem.
    • ro: Root filesystem initially mounted read-only during early boot.
    • quiet: Reduces kernel console output.
    • splash: Enables a graphical boot splash on systems that support it.
  • stat /boot/vmlinuz*: Displays file metadata for kernel images under /boot.
    • Access: Last access time.
    • Modify: Last content modification time.
    • Change: Last metadata change time.
  • ls -l /sbin/init: Shows what init binary /sbin/init points to.
    • -l: Long listing format (permissions, owner, and symlink target).
    • /sbin/init: Conventional init entrypoint that points to the real init system.
    • /lib/systemd/systemd: Indicates systemd is the init system in use.