Table of Contents
From Bootloader to Kernel
When the bootloader has finished its own work, control passes to the Linux kernel. This transition is the beginning of kernel loading. At this point, the firmware has handed control to the bootloader, the bootloader has been selected and configured, and now the kernel image itself is brought into memory and started. In a modern Linux system this process involves the kernel binary, the initramfs, and a set of parameters that define how the kernel should behave during early boot.
Understanding this stage is essential if you want to diagnose low level boot problems, tune kernel behavior with parameters, or troubleshoot why a particular device or filesystem is not available early in the boot sequence.
Kernel Image and Its Placement in Memory
The Linux kernel is stored on disk as a compressed image file, usually called something like vmlinuz-6.8.0-xyz on many distributions. The letter z in the name indicates that the image is compressed. The bootloader is responsible for reading this file from the filesystem and placing it in RAM.
Classically, on BIOS systems, the bootloader must load the kernel into a region of low physical memory that the kernel expects. On UEFI systems, the rules are more flexible, but the bootloader still needs to place the kernel where it can safely decompress itself and operate without clashing with important firmware structures.
The kernel image is a self extracting binary. It contains a small decompression stub that executes first, unpacks the core kernel into its final memory location, and then jumps into the main kernel entry point. From the perspective of the bootloader, this is simple. It only needs to copy the given kernel image into memory and pass control along with some information about the system and the boot configuration.
The bootloader must load the exact kernel image file and must not modify its contents. Any corruption of the kernel image in RAM or on disk will lead to boot failures or undefined behavior.
Early Boot Protocol and Hand-Off
There is a defined protocol that describes how the bootloader must invoke the Linux kernel. On BIOS systems this is often referred to as the Linux boot protocol. On UEFI systems the kernel can also be packaged as a PE executable, which means the firmware itself can load the kernel, but most distributions still use a dedicated bootloader that implements the same protocol at a higher level.
The hand-off from bootloader to kernel has three critical parts. First, the kernel image must be loaded into memory in accordance with the protocol, including its real mode header or EFI entry point. Second, the bootloader must supply a description of the hardware and memory layout, traditionally through structures derived from BIOS, and on modern systems through ACPI and UEFI tables. Third, the bootloader must provide the kernel command line, which is a string of parameters that influence the kernel behavior.
Once these elements are in place, the bootloader jumps to the kernel entry address. At this instant, the bootloader has finished its role. From this point onward, the kernel controls the system, and will not return to the bootloader.
Kernel Decompression and Relocation
The kernel image stored on disk is compressed to save space and reduce disk I/O at boot time. Common compression formats include gzip, xz, and others, depending on how the kernel was built. The bootloader does not need to know the compression format. The decompression stub that is part of the kernel image handles this.
The sequence is as follows. The decompression stub executes in a very simple execution environment. It runs with interrupts disabled, limited stack, and minimal assumptions about hardware initialization. It first sets up enough low level state to read and write memory safely, then decompresses the compressed kernel payload into its intended physical address range. This process is sometimes called relocation, because the decompressed kernel may reside at a different address than the compressed image.
After decompression, the stub clears any temporary data structures that are no longer needed, sets up a minimal execution context such as a temporary page table for early paging, and finally jumps into the main kernel entry function, often called start_kernel in the kernel source code.
The kernel decompression phase must succeed before any higher level initialization can begin. If decompression fails or the image is loaded at an incompatible address, the system will hang or reset long before any messages appear on the screen.
Role of the Initramfs During Kernel Loading
On most modern distributions, the kernel is not loaded alone. It is accompanied by an initial RAM filesystem, or initramfs, which is also read by the bootloader from disk and placed into memory. The initramfs is a compressed cpio archive that contains user space utilities, scripts, libraries, and sometimes kernel modules needed for early system initialization.
The bootloader passes the address of the initramfs in memory to the kernel along with the kernel command line. The kernel is aware that an initramfs is attached, and during early initialization it unpacks the archive into a temporary root filesystem in RAM.
At this stage, no persistent disks are mounted yet. The initramfs environment is used to load necessary modules for disk controllers, network interfaces, and filesystems, and to perform tasks such as unlocking encrypted volumes or assembling software RAID. After these tasks are done, the system can locate and mount the real root filesystem that will be used for normal operation.
If the initramfs is missing required modules or tools, the kernel may be unable to access the root filesystem. This leads to early boot failures where the kernel drops to an emergency shell or repeatedly reports that it cannot find the root device.
Kernel Command Line and Early Configuration
When the kernel starts, one of the first configuration inputs it reads is the kernel command line. This is a plain text string that the bootloader sends to the kernel. It contains parameters in the form name=value or simple flags. These parameters influence both early kernel behavior and settings that control which root filesystem to mount and how to handle certain drivers.
A typical example contains directives like root=/dev/sda2, filesystem type hints, log level controls, or special options for graphics drivers. Some parameters are consumed directly by the core kernel, while others are parsed by particular subsystems or device drivers. Parameters that are not recognized by the kernel itself may be passed along to the first user space process, which often resides in the initramfs.
The kernel parses this command line very early in the boot process, well before regular user space is available. Certain severe boot problems can only be resolved by adjusting command line options, for example forcing the kernel to use a particular hardware clock source or disabling a buggy driver.
Critical boot parameters such as root= and options that disable security features can fundamentally change system behavior. Misconfiguration of the kernel command line can prevent the system from booting or weaken its security.
Architecture Specific Considerations
Kernel loading details differ across processor architectures, though the broad concepts remain the same. On x86, the kernel must first start in a mode compatible with legacy firmware expectations, then switch itself into protected mode and often later into long mode for 64 bit operation. This multi stage transition is handled entirely within the early kernel code after the bootloader transfers control.
On 64 bit ARM systems, UEFI firmware and loaders typically enter the kernel at a defined 64 bit entry point, which simplifies the mode switching process, but it still requires careful management of memory mappings and cache configuration during the first instructions of kernel execution. Other architectures follow their own conventions, including special processor states or registers that must be initialized by the bootloader, the firmware, or the kernel itself.
From an administrator perspective, these architectural differences mostly remain hidden, but they can become relevant when debugging low level problems with vendor specific hardware or nonstandard firmware implementations.
Transition to Initramfs and Real Root
Once the kernel has decompressed, initialized essential subsystems, parsed the command line, and uncompressed the initramfs, it moves to the final phase of kernel loading. Here, the kernel starts the first user space process from the initramfs, often a program named init or sometimes a shell script.
In this environment, user space tools run on top of minimal kernel services and device discovery. The goal is to prepare the system to pivot from the temporary RAM based root filesystem to the permanent root filesystem on disk, network, or another medium. This pivot usually involves loading additional kernel modules, discovering disks, handling encryption or RAID, and then mounting the intended root.
When the permanent root filesystem is ready, the initramfs code switches the root of the process tree to that filesystem and executes the real system init process described by your distribution. From this point on, the kernel loading phase is effectively complete, and the regular user space boot sequence continues.
Understanding this transition clarifies why problems in either the initramfs contents or the kernel command line often surface as failures to mount the root filesystem, even though the kernel image itself has loaded and started successfully.