The Many Paths to init, Part 4: The Specialists

The Mobile Ecosystem: The Android Boot Flow

The Android boot process is a masterclass in vertical integration, engineered for security and reliability at a massive consumer scale.

• The boot.img Artifact: The central component is the boot.img file, a specially formatted binary that packages the kernel, a ramdisk, and a metadata header. The final bootloader stage, the Android Bootloader (ABL), parses this header to load the kernel.

• Generic Kernel Image (GKI): To combat ecosystem fragmentation, modern Android uses a Generic Kernel Image (GKI). This decouples the core, Google-maintained kernel from device-specific components. The boot partition contains the generic kernel, while a separate vendor_boot partition holds all the device-specific drivers, kernel modules, and the Device Tree Blob (DTB). This architecture allows Google to push core kernel security updates directly, bypassing vendor integration bottlenecks.

• Android Verified Boot (AVB): AVB establishes an unbroken chain of trust from the hardware Boot ROM to the system partitions. Each stage cryptographically verifies the next, and the device’s security state is communicated to the user with color-coded warning screens (e.g., ORANGE for an unlocked bootloader, RED for a verification failure).

The Mainframe Environment: Linux on IBM Z

Booting Linux on an IBM Z mainframe follows a unique paradigm shaped by decades of mainframe design principles.

• Initial Program Load (IPL): The process of “booting” is called an Initial Program Load (IPL). It is not an automatic discovery process but an explicit command issued by an operator through the Hardware Management Console (HMC).

• The zipl Tool: The primary tool for preparing a boot device is zipl (z/OS Initial Program Loader). It is not an interactive bootloader but a deployment tool run from a live system. It takes the kernel, initramfs, and parameters and writes a boot record onto the target storage device, making it IPL-able.

• Virtualization Contexts: The process differs depending on the virtualization context. In a hardware-level Logical Partition (LPAR), the IPL is initiated directly by the HMC. When running as a KVM guest, the hypervisor provides a standardized bootloader image (s390-ccw.img) to the guest, bypassing the need for a zipl-prepared disk.

The Virtualized Platform: QEMU/KVM Guests

In a virtualized environment like QEMU/KVM, the hardware is software-defined, making the boot process a highly configurable abstraction.

• Emulated Firmware: QEMU provides virtual firmware for its guests. This can be SeaBIOS, which emulates a traditional legacy BIOS, or OVMF, which provides a full-featured UEFI environment, enabling modern features like Secure Boot within the virtual machine.

• Direct Kernel Boot: For rapid development and testing, QEMU offers a powerful feature called direct kernel boot. Using command-line options (-kernel, -initrd, -append), a user can instruct QEMU to load a kernel and initramfs directly from the host filesystem, completely bypassing the virtual firmware and any bootloader on the guest’s virtual disk. This is invaluable for kernel developers, allowing them to test a new build in seconds.

Despite their profound differences, these platforms all face common challenges in securing the boot chain and ensuring system updates are reliable. In our final article, we will explore the cross-platform themes of Secure Boot and atomic updates.