SwadhyAI Notes

All Operating Systems notes

Boot chain · Fundamentals

Boot process and hardware overview

From power-on to first user process

Start here

Bootstrapping is the first story of an OS: nothing in your textbook about scheduling matters until firmware has found memory, loaded a kernel image, and jumped into its entry point. Read the definition, then follow the numbered timeline, each step answers “what could fail here?”

Bootstrapping (theory)

Bootstrapping is the sequence from power-on (or VM launch) to the first meaningful user-space process (traditionally init / systemd as PID 1). Firmware initializes minimal hardware, loads a bootloader or kernel stub, passes a memory map and command line, and transfers control in a privileged CPU mode.

The early kernel must bring up paging, trap vectors, console output, and often SMP (other CPU cores) before it can mount a root filesystem and execute execve on init. Initramfs exists because some drivers or crypto unlock steps are required before the real root disk can be mounted.

By the end of this page you should be able to

  1. List the main handoff stages from firmware to PID 1.
  2. Explain why ACPI/UEFI tables matter even when you never “program firmware.”
  3. Contrast initramfs with the on-disk root filesystem.
  4. Name one security feature that influences boot (e.g. Secure Boot) and what it verifies.

Chain of trust (conceptual)

Security begins before the OS is fully in control.

Firmware trust

UEFI Secure Boot can cryptographically verify bootloader and kernel images using keys rooted in firmware. If verification fails, the chain stops, protecting against persistent bootkits.

ACPI / device tables

ACPI describes CPUs, IRQ routing, and sleep states; the kernel parses tables to configure drivers. Bugs here cause “works on one board” failures.

Device tree (embedded)

Many ARM systems use a DTB instead of ACPI: a compiled description of buses and peripherals the kernel matches to drivers at boot.

PID 1 role

The first real user process reparents orphans, adopts zombie cleanup responsibilities, and orchestrates shutdown. If init dies, user-visible recovery is limited.

TL;DR

Boot is a chain of trust: firmware initializes hardware, a bootloader loads the kernel image and passes a memory map + cmdline, early kernel assembly sets up paging and stacks, subsystem init brings up drivers, then `init` becomes PID 1 in user mode.

Bootstrapping is operating systems work even before “scheduling” lectures begin. Understanding handoff artifacts (cmdline, initrd, EFI variables) explains how kdump, kexec, and cloud images configure the same kernel differently.

Sequence: firmware → init

High-level message flow (simplified).
Diagram text: the exact Mermaid definition below preserves the nodes, labels, and connections. Enable JavaScript to view the rendered diagram.
Read the diagram definition
sequenceDiagram
  participant FW as Firmware
  participant BL as Bootloader
  participant K as Kernel
  participant I as init
  FW->>BL: handoff + mem map
  BL->>K: load + jump
  K->>K: decompress, SMP, drivers
  K->>I: exec init
Bootstrapping establishes memory maps, relocates the kernel, brings up SMP, mounts rootfs, and spawns init, each step assumes the previous firmware tables were sane. Debugging “early boot” issues often means serial consoles and `initcall_debug`, not printf in user space.

Boot timeline (numbered theory)

Each step assumes the previous artifacts are sane.
01

Firmware handoff

UEFI/ACPI provides memory map, framebuffer, and NUMA SRAT; kernel must not clobber reserved regions.

02

Decompress & relocate

zImage/bzImage paths differ; KASLR randomizes placement when enabled.

03

Bring-up CPUs

APs start in real mode or firmware trampoline; per-CPU areas and IPIs initialized.

04

Run init

Kernel thread becomes PID1 (`systemd`); user policy takes over while retaining cgroup/namespace hooks.

Kernel & hardware insights

Real mode → protected/long mode

x86 history matters: firmware may start 16-bit; boot stubs switch modes before C code runs. ARM systems differ but still have firmware handoff.

Device tree (embedded)

ARM64 often uses DTB instead of ACPI to describe hardware, kernel matches drivers to nodes.

Early printk and traps

Before full console drivers, kernels use simple UART output; panic paths must still print something useful.

PID 1 responsibilities

Adopt orphans, reap zombies, handle shutdown, if init crashes, the system is effectively stuck.

Did you know?

  • ▸Secure Boot verifies signatures on bootloaders and kernels using keys fused in firmware, OS integrity starts before the OS runs.
  • ▸ACPI tables describe CPUs, IRQ routing, and sleep states, parsing bugs cause “works on one laptop” issues.
  • ▸Initramfs may contain a minimal userland that loads real root from LUKS or network (PXE).

Boot pitfalls

Assuming contiguous RAM

Hole lists from firmware require careful early allocator; bad maps cause mysterious crashes at MB scale.

Secure Boot keys

Unsigned initramfs or mismatched MOK blocks upgrades, distinguish boot policy from runtime bugs.

Glossary

ACPI
Advanced Configuration and Power Interface, tables describing devices, IRQ routing, and power states.
initramfs
CPIO archive loaded into tmpfs for early userspace helpers before pivot_root.
KASLR
Kernel address space layout randomization, mitigates memory corruption exploits.

Follow-ups

  1. What is the difference between bootloader stage1 and the kernel’s own `decompress_kernel`?
  2. Why might `quiet` kernel parameter slow incident response?
  3. How does initramfs differ from rootfs on disk?

Cloud images

Cloud-init / ignition scripts run early user space to fetch SSH keys, still orchestrated atop kernel + init design.

Why not jump straight to desktop?

You need working storage drivers, root filesystem mount, devtmpfs, and policy for which binaries may run, incremental bring-up reduces failure blast radius.

Map your laptop

Boot with `systemd` journal: identify firmware → loader → kernel → init transitions in logs.

Kernel cmdline (Linux)

Terminal
cat /proc/cmdline

Self-check

1The first traditional user-space process on many Unix systems is…

2Initramfs mainly helps with…

3Secure Boot is about…