The Linux booting process involves multiple stages and is in many ways similar to the BSD and other Unix-style boot processes, from which it is derived. Although the Linux booting process depends very much on the computer architecture, those architectures share similar stages and software components, including system startup, bootloader execution, loading and startup of a Linux kernel image, and execution of various startup scripts and daemons. Those are grouped into 4 steps: system startup, bootloader stage, kernel stage, and init process.
When a Linux system is powered up or reset, its processor will execute a specific firmware/program for system initialization, such as the power-on self-test, invoking the reset vector to start a program at a known address in flash/ROM (in embedded Linux devices), then load the bootloader into RAM for later execution. In IBM PC–compatible personal computers (PCs), this firmware/program is either a BIOS or a UEFI monitor, and is stored in the mainboard. In embedded Linux systems, this firmware/program is called boot ROM. After being loaded into RAM, the bootloader (also called first-stage bootloader or primary bootloader) will execute to load the second-stage bootloader (also called secondary bootloader). The second-stage bootloader will load the kernel image into memory, decompress and initialize it, and then pass control to this kernel image. The second-stage bootloader also performs several operations on the system such as system hardware check, mounting the root device, loading the necessary kernel modules, etc. Finally, the first user-space process (init process) starts, and other high-level system initializations are performed (which involve with startup scripts).
For each of these stages and components, there are different variations and approaches; for example, GRUB, systemd-boot, coreboot or Das U-Boot can be used as bootloaders (historical examples are LILO, SYSLINUX or Loadlin), while the startup scripts can be either traditional init-style, or the system configuration can be performed through modern alternatives such as systemd or runit.
System startup System startup has different steps based on the hardware that Linux is being booted on.
IBM PC compatible hardware is one architecture Linux is commonly used on; on these systems, the BIOS or UEFI firmware plays an important role.
In BIOS systems, the BIOS will respectively perform power-on self test (POST), which is to check the system hardware, then enumerate local device and finally initialize the system. For system initialization, BIOS will start by searching for the bootable device on the system which stores the OS. A bootable device can be storage devices like floppy disk, CD-ROM, USB flash drive, a partition on a hard disk (where a hard disk stores multiple OS, e.g Windows and Fedora), a storage device on local network, etc. A hard disk to boot Linux stores the Master Boot Record (MBR), which contains the first-stage/primary bootloader in order to be loaded into RAM.
In UEFI systems, the Linux kernel can be executed directly by UEFI firmware via the EFI boot stub, but usually uses GRUB 2 or systemd-boot as a bootloader.
If UEFI Secure Boot is supported, a "shim" or "Preloader" is often booted by the UEFI before the bootloader or EFI-stub-bearing kernel. Even if UEFI Secure Boot is disabled this may be present and booted in case it is later enabled. It merely acts to add an extra signing key database providing keys for signature verification of subsequent boot stages without modifying the UEFI key database, and chains to the subsequent boot step the same as the UEFI would have.
The system startup stage on embedded Linux system starts by executing the firmware / program on the on-chip boot ROM, which then load bootloader / operating system from the storage device like eMMC, eUFS, NAND flash, etc. The sequences of system startup varies by processors but all include hardware initialization and system hardware testing steps. For example in a system with an i.MX7D processor and a bootable device which stores the OS (including U-Boot), the on-chip boot ROM sets up the DDR memory controller at first which allows the boot ROM's program to obtain the SoC configuration data from the external bootloader on the bootable device. The on-chip boot ROM then loads the U-Boot into DRAM for the bootloader stage.
Bootloader stage In IBM PC compatibles using a BIOS, the first stage bootloader, which is a part of the master boot record (MBR), is a 512-byte image containing the vendor-specific program code and a partition table. As mentioned earlier in the introduction part, the first stage bootloader will find and load the second stage bootloader. It does this by searching in the partition table for an active partition. After finding an active partition, first stage bootloader will keep scanning the remaining partitions in the table to ensure that they're all inactive. After this step, the active partition's boot record is read into RAM and executed as the second stage bootloader. The job of the second stage bootloader is to load the Linux kernel image into memory, and optional initial RAM disk. Kernel image isn't an executable kernel, but a "compressed file" of the kernel instead, compressed into either zImage or bzImage formats with zlib.
In those systems, the first- and second-stage bootloaders are usually provided by the GRand Unified Bootloader (GRUB), and formerly provided by the Linux Loader (LILO). GRUB 2, which is now used, differs from GRUB 1 by being capable of automatic detection of various operating systems and automatic configuration. The stage1 is loaded and executed by the BIOS from the MBR. The intermediate stage loader (stage1.5, usually core.img) is loaded and executed by the stage1 loader. The second-stage loader (stage2, the /boot/grub/ files) is loaded by the stage1.5 and displays the GRUB startup menu that allows the user to choose an operating system or examine and edit startup parameters. After a menu entry is chosen and optional parameters are given, GRUB loads the linux kernel into memory and passes control to it. GRUB 2 is also capable of chain-loading of another bootloader.
In UEFI systems, the stage1 and stage1.5 usually are the same UEFI application file (such as grubx64.efi for x64 UEFI systems).
Beside GRUB, there are some more popular bootloaders: systemd-boot (formerly Gummiboot), a bootloader included with systemd that requires minimal configuration (for UEFI systems only). SYSLINUX/ISOLINUX is a bootloader that specializes in booting full Linux installations from FAT filesystems. It is often used for boot or rescue floppy discs, live USBs, and other lightweight boot systems. ISOLINUX is generally used by Linux live CDs and bootable install CDs. rEFInd, a boot manager for UEFI systems. coreboot is a free implementation of the UEFI or BIOS and usually deployed with the system board, and field upgrades provided by the vendor if need be. Parts of coreboot becomes the systems BIOS and stays resident in memory after boot. Das U-Boot is a bootloader for embedded systems. It is used on systems that do not have a BIOS/UEFI but rather employ custom methods to read the bootloader into memory and execute it.
Historical bootloaders, no longer in common use, include:
LILO does not understand or parse filesystem layout. Instead, a configuration file (/etc/lilo.conf) is created in a live system which maps raw offset information (mapper tool) about location of kernel and ram disks (initrd or initramfs). The configuration file, which includes data such as boot partition and kernel pathname for each, as well as customized options if needed, is then written together with bootloader code into MBR bootsector. When this bootsector is read and given control by BIOS, LILO loads the menu code and draws it then uses stored values together with user input to calculate and load the Linux kernel or chain-load any other boot-loader. GRUB 1 includes logic to read common file systems at run-time in order to access its configuration file. This gives GRUB 1 ability to read its configuration file from the filesystem rather than have it embedded into the MBR, which allows it to change the configuration at run-time and specify disks and partitions in a human-readable format rather than relying on offsets. It also contains a command-line interface, which makes it easier to fix or modify GRUB if it is misconfigured or corrupt. Loadlin is a bootloader that can replace a running DOS or Windows 9x kernel with the Linux kernel at run time. This can be useful in the case of hardware that needs to be switched on via software and for which such configuration programs are proprietary and only available for DOS. This booting method is less necessary nowadays, as Linux has drivers for a multitude of hardware devices, but it has seen some use in mobile devices. Another use case is when the Linux is located on a storage device which is not available to the BIOS for booting: DOS or Windows can load the appropriate drivers to make up for the BIOS limitation and boot Linux from there.
Kernel The kernel stage occurs after the bootloader stage. The Linux kernel handles all operating system processes, such as memory management, task scheduling, I/O, interprocess communication, and overall system control. This is loaded in two stages – in the first stage, the kernel (as a compressed image file) is loaded into memory and decompressed, and a few fundamental functions are set up such as basic memory management, minimal amount of hardware setup. The kernel image is self-decompressed, which is a part of the kernel image's routine. For some platforms (like ARM 64-bit), kernel decompression has to be performed by the bootloader instead, like U-Boot.
For details of those steps, take an example with i386 microprocessor. When its bzImage is invoked, function start() (of ./arch/i386/boot/head.S) is called to do some basic hardware setup then calls startup_32() (located in ./arch/i386/boot/compressed/head.S). startup_32()will do basic setup to environment (stack, etc.), clears the Block Started by Symbol (BSS) then invokes decompress_kernel() (located in ./arch/i386/boot/compressed/misc.c) to decompress the kernel. Kernel startup is then executed via a different startup_32() function located in ./arch/i386/kernel/head.S. The startup function startup_32() for the kernel (also called the swapper or process 0) establishes memory management (paging tables and memory paging), detects the type of CPU and any additional functionality such as floating point capabilities, and then switches to non-architecture specific Linux kernel functionality via a call to start_kernel() located in ./init/main.c.