Chapter 2: The Boot Process in Depth

Updated

October 31, 2026

Chapter 2: The Boot Process in Depth

To understand how multiple kernels can be booted, partitioned, or transitioned sequentially on a physical bare-metal system, we must examine the boot path in rigorous detail. This chapter explores the UEFI environment, bootloader handoff protocols, kernel command-line configuration for resource isolation, initramfs architecture, and the transition to userspace.

Firmware and the EFI Environment

Modern x86_64 and ARM64 servers utilize Unified Extensible Firmware Interface (UEFI) specification v2.8+ firmware:

  • UEFI System Table: The firmware exposes Boot Services (available only before the OS exits firmware) and Runtime Services (such as NVRAM variable access, available throughout OS runtime).
  • EFI System Partition (ESP): A standard FAT32 partition (GUID: C12A7328-F81F-11D2-BA4B-00A0C93EC93B) containing UEFI binaries (/EFI/BOOT/BOOTX64.EFI, /EFI/ubuntu/grubx64.efi).
  • NVRAM Boot Variables: Non-volatile variables (Boot0001, BootOrder) managed via efibootmgr determine the firmware boot priority and path to initial executables.

When bootstrapping an isolated multi-kernel environment, the UEFI firmware can either launch a primary bare-metal kernel (which subsequently provisions guest kernels), or a hypervisor shim layer (such as Xen or a minimal hypervisor bootloader) that partitions hardware before either kernel begins execution.

Bootloaders: GRUB, systemd-boot, and Others

The bootloader bridges firmware services and the operating system kernel:

  • GRUB2: Complex, modular bootloader supporting complex scripting, dynamic menu generation, network PXE booting, and diverse filesystem drivers.
  • systemd-boot: Minimalist, text-only UEFI boot manager implementing the Boot Loader Specification (BLS). Fast and deterministic, it relies strictly on UEFI filesystem drivers.
  • Unified Kernel Images (UKI): Single UEFI PE binaries combining the Linux kernel (vmlinuz), initramfs, boot command line, and an optional splash image into an authenticated, digitally signed executable.

Bootloader configuration allows operators to define distinct boot profiles: one for single-kernel production, one for hardware isolation and VFIO passthrough staging, and one for hypervisor-based partitioning.

Kernel Command-Line Parameters

Kernel command-line parameters passed via the bootloader configure hardware reservation and isolation mechanisms before any device drivers load. For multi-kernel host preparation, key parameters include:

Parameter Purpose Example Value
isolcpus Isolates specified CPU cores from the CFS scheduler isolcpus=managed_irq,domain,16-31
nohz_full Enables tickless execution on specified cores nohz_full=16-31
rcu_nocbs Offloads RCU callback processing from isolated cores rcu_nocbs=16-31
intel_iommu / amd_iommu Enables hardware IOMMU translation units intel_iommu=on iommu=pt
hugepagesz / hugepages Reserves static 1GB or 2MB hugepages at boot hugepagesz=1G default_hugepagesz=1G hugepages=64
vfio-pci.ids Binds target PCIe device IDs directly to VFIO vfio-pci.ids=10de:2204,10de:1aef
memmap Carves out or reserves physical memory address ranges memmap=64G$64G

Configuring these parameters ensures the primary host kernel does not bind to hardware resources intended for secondary isolated kernels.

Initramfs Construction and Role

The initial ramdisk (initramfs) is a gzipped or zstd-compressed CPIO archive loaded into memory alongside the kernel:

  1. Driver Staging: Supplies kernel modules required to access the root storage fabric (such as nvme, mpt3sas, multipath, virtio_blk).
  2. Device Discovery & Crypto: Executes udevd to discover block devices, opens LUKS encrypted volumes via cryptsetup, and assembles LVM or mdadm RAID arrays.
  3. VFIO Device Unbinding: In multi-kernel architectures, early initramfs scripts can unbind specific PCIe devices from native drivers before root mount, binding them to vfio-pci to prevent host driver claiming.
  4. The switch_root Operation: Mounts the real root filesystem, deletes the initramfs contents, moves the root mount to /, and executes the init binary (/sbin/init or /lib/systemd/systemd).

The Handoff to Userspace

The handoff from kernel to userspace occurs when kernel_init() invokes run_init_process("/sbin/init"):

  • The process receives Process ID 1 (PID 1) and inherits execution context.
  • Systemd establishes basic cgroup hierarchies, mounts essential virtual filesystems (/proc, /sys, /dev), and starts the systemd-journald logging service.
  • Systemd evaluates target dependency units, brings up local networking, and starts virtualization or partitioning daemons (such as libvirtd, qemu, or custom partition controllers).
  • In a multi-kernel server, a designated systemd target (multikernel.target) can automatically initialize hugepage pools, verify VFIO binding, and launch secondary kernel instances.