Compressed Kernel

Boot Process Overview

The following details the steps involved in the Linux Operating System’s booting process:

1. Power On & Initialisation: Upon powering up, the system firmware, whether it’s BIOS or UEFI, conducts a POST and initializes the hardware components.

2. Boot Device Selection: The firmware scans for bootable devices, targeting the Master Boot Record (MBR) in BIOS systems or the EFI System Partition in UEFI setups. From this location, the boot loader, GRUB2, is fetched.

3. GRUB2 Execution: GRUB2 activates, reads its configuration from grub.cfg, and displays a boot menu to the user, listing available kernels and other boot choices.

4. Kernel Loading: Post kernel selection (or after the default choice times out), GRUB2 loads the chosen kernel alongside its respective initramfs image into memory. Following this, the kernel is uncompressed and initiated.

5. Kernel Initialisation: Following its load, the kernel sets up system hardware and triggers the /sbin/init script. Notably, this script is directly linked to the systemd binary which is assigned PID 1.

6. System Initialisation: Here, systemd steps in, orchestrating the system initialisation based on the defined or default target.

Why is the Kernel Compressed?

A closer look at the “Kernel Loading” step left me pondering: Why keep the Kernel compressed only to decompress it upon loading? Doesn’t this introduce an extra step in booting, potentially elongating the load time?

To quench my curiosity, I delved deeper and unearthed the following justifications:

1. Disk Space Conservation: A main reason for kernel compression traces back to the early ’90s, the dawn of Linux. Given the limited and pricey storage back then, kernel compression economised significant disk space.

2. Swift Loading: Counterintuitively, reading a compact, compressed kernel from storage followed by its decompression in memory is speedier than directly reading an uncompressed, larger kernel.

3. For Embedded and Limited-resource Systems: Beyond desktops and servers, Linux thrives in embedded systems where storage is scarce. In these settings, every byte is invaluable, underscoring the need for compression.

4. Network Booting: For instances where the kernel is network-retrieved (as seen in PXE boot cases), a compressed kernel translates to reduced data transfer, accelerating boot durations.

5. Initial RAM Disk (initrd) and Initial RAM FileSystem (initramfs): These systems, often paired with the kernel, house modules and drivers crucial for early-boot before the primary filesystems come into play. Compressing the kernel and these systems synergistically slashes the boot image size.

6. Cutting-edge Compression Techniques: Contemporary compression algorithms are both rapid and adept. The minimal overhead ensures a speedy decompression, making the compression-decompression trade-off sensible.

7. Optimal Memory Utilization: Retaining the compressed kernel up until its need optimizes RAM usage. Despite the in-memory decompression during boot, there’s no requisite for an uncompressed disk variant, thereby conserving storage.

In conclusion, even though the decompression might seem like an added chore in the boot sequence, its duration is often eclipsed by the manifold advantages, especially in dated or constrained systems. Here, the time saved in I/O operations—attributed to lesser storage reads—often trumps the decompression time.