Linux

Boot — from bootloader handoff to PID 1

Where Bootloaders leaves off: the moment the bootloader jumps into the kernel image, through to the first userspace process starting.

Quick reference

What it is: The sequence from bootloader handoff, through kernel init and (optionally) an initramfs, to PID 1 starting.
Mental model: A relay race: bootloader hands the baton to the kernel, the kernel hands it to an initramfs (maybe), which hands it to the real init.
Key numbers: Kernel command line configures early boot behavior; PID 1 exiting always panics the kernel.
Reach for it when: Debugging why a board won't boot, or building a custom root filesystem/init strategy.

The handoff

The bootloader (see U-Boot) loads the kernel image and, on most embedded platforms, a device tree blob (DTB) into RAM, then jumps to the kernel's entry point with a pointer to that DTB (or, on x86, passes boot parameters differently via a boot protocol). The device tree describes the hardware — memory layout, peripherals, clocks — so the same kernel binary can support many boards without being recompiled for each one.

Kernel early boot

Architecture-specific low-level setup (MMU, initial page tables, CPU mode).
Decompress the kernel if it was stored compressed (zImage/uImage).
Parse the device tree, set up memory management proper, initialize core subsystems.
Probe and initialize drivers for devices described in the device tree, roughly in dependency order.
Mount the root filesystem — either directly, or via an initramfs.
Execute /sbin/init (or whatever init= specifies) as PID 1.

Why an initramfs?

An initramfs is a small filesystem image bundled into RAM alongside the kernel, unpacked and run before the real root filesystem is available. Common reasons to need one:

The real root filesystem lives somewhere the kernel can't reach without extra driver/module setup first (e.g. an encrypted or network filesystem).
You want an early userspace stage to pick between multiple root filesystems (A/B update schemes) before handing off.
Loading needed kernel modules that aren't statically built in.

Once its job is done, the initramfs typically switch_roots (or pivot_roots) into the real root filesystem and execs the real init there.

Kernel command line

A string passed by the bootloader that configures early kernel behavior without recompiling anything — e.g. console=ttyS0,115200 (where to send early boot logs), root=/dev/mmcblk0p2 (which partition is the root filesystem), init=/sbin/init. Visible at runtime via /proc/cmdline.

PID 1 and beyond

Whatever init system is configured (systemd, BusyBox init, a custom minimal init) becomes PID 1 and is responsible for bringing up the rest of userspace — mounting remaining filesystems, starting services, reaping orphaned processes. If PID 1 ever exits, the kernel panics — there is no next process to hand control to.

Real-world applications

Custom embedded Linux images (Yocto, Buildroot) — every board bring-up involves getting exactly this handoff sequence working for new hardware.
A/B update systems — the kernel command line and initramfs are commonly used to select which root partition to boot for atomic, rollback-capable updates (see Snap types & Ubuntu Core).
Recovery/rescue modes — many devices boot into a minimal initramfs-only environment for factory reset or firmware recovery, without ever mounting the normal root filesystem.
Secure boot chains — verifying the kernel and initramfs signature is part of the same handoff this page describes, continuing the chain of trust from Bootloader fundamentals.

What I learned

"No display output" during boot debugging is very often a console configuration problem (console= pointing at the wrong UART, or missing entirely), not a kernel-not-booting problem. Checking the bootloader console log and the kernel's own console= argument is a cheap first step before assuming the kernel crashed.