Android, IBM Z, and QEMU/KVM each take a boot approach specialized for their environment. Android packages the kernel, ramdisk, and metadata into a boot.img verified by Android Verified Boot, with a separate vendor_boot partition holding device-specific drivers via the Generic Kernel Image scheme. IBM Z mainframes use an operator-issued Initial Program Load prepared by the zipl tool, while QEMU/KVM can emulate firmware such as SeaBIOS or OVMF, or skip it entirely with direct kernel boot for fast development testing.
Beyond PCs and general-purpose embedded systems lie platforms where the Linux boot process has been specialized to an extreme degree. In this installment, we explore three of these unique environments: the security-focused world of Android, the legacy-rich domain of IBM Z mainframes, and the software-defined flexibility of QEMU/KVM virtualization.
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.
Frequently asked questions
What is the boot.img file in Android?
The boot.img is a specially formatted binary that packages the kernel, a ramdisk, and a metadata header. The Android Bootloader (ABL) parses this header to load the kernel.
What problem does the Generic Kernel Image (GKI) solve?
GKI decouples the core, Google-maintained kernel from device-specific components. The boot partition holds the generic kernel while a separate vendor_boot partition holds device-specific drivers, kernel modules, and the Device Tree Blob, letting Google push kernel security updates directly without waiting on vendors.
What is an Initial Program Load (IPL) on IBM Z?
An IPL is the IBM Z term for booting. Unlike an automatic discovery process, it is an explicit command issued by an operator through the Hardware Management Console (HMC), and the zipl tool prepares the boot device beforehand.
What is QEMU direct kernel boot used for?
Direct kernel boot lets a user load a kernel and initramfs straight from the host filesystem using options like -kernel, -initrd, and -append, completely bypassing virtual firmware and any guest bootloader. It is invaluable for kernel developers testing new builds quickly.
