Booting process of Linux: Difference between revisions

Revision as of 02:44, 20 August 2024

Revision as of 03:08, 20 August 2024

Line 1:

{{Short description|Multi-stage initialisation process}}

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 derives. Although the Linux booting process depends very much on the computer architecture, those architectures share similar stages and software components,{{Sfn|M. Tim Jones|2006|ps=, "The process of booting a Linux® system consists of a number of stages. But whether you're booting a standard x86 desktop or a deeply embedded PowerPC® target, much of the flow is surprisingly similar."|loc="Introduction"}} including system startup, [[bootloader]] execution, loading and startup of a [[Linux kernel]] image, and execution of various [[startup scripts]] and [[Daemon (computing)|daemons]].{{Sfn|M. Tim Jones|2006|ps=, "Figure 1. The 20,000-foot view of the Linux boot process"|loc="Overview"}} Those are grouped into '''4 steps''': '''system startup''', '''bootloader stage''', '''kernel stage''', and '''init process'''.{{Sfn|M. Tim Jones|2006|ps=|loc="Linux booting process are grouped into 4 stages, based on IBM source"}} 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.{{Sfn|M. Tim Jones|2006|ps=, "Figure 1. The 20,000-foot view of the Linux boot process"|loc="Overview"}} In [[IBM PC–compatible]] [[personal computers]] (PCs), this firmware/program is either a [[BIOS]] or a [[UEFI]] monitor, and is stored in the mainboard.{{Sfn|M. Tim Jones|2006|ps=, "Figure 1. The 20,000-foot view of the Linux boot process"|loc="Overview"}} In embedded Linux systems, this firmware/program is called [[boot ROM]].<ref>{{Cite book |last1=Bin |first1=Niu |title=2020 International Symposium on Computer Engineering and Intelligent Communications (ISCEIC) |last2=Dejian |first2=Li |last3=Zhangjian |first3=LU |last4=Lixin |first4=Yang |last5=Zhihua |first5=Bai |last6=Longlong |first6=He |last7=Sheng |first7=Liu |date=August 2020 |isbn=978-1-7281-8171-4 |pages=5–8 |chapter=Research and design of Bootrom supporting secure boot mode |doi=10.1109/ISCEIC51027.2020.00009 |chapter-url=https://ieeexplore.ieee.org/document/9325327 |s2cid=231714880}}</ref>{{Sfn|Alberto Liberal De Los Ríos|2017|loc=, "Linux Boot Process"|p=28}} After being loaded into RAM, the bootloader (also called '''first-stage bootloader''' or '''primary bootloader''') will execute to load the '''second-stage bootloader'''{{Sfn|M. Tim Jones|2006|ps=, "Figure 1. The 20,000-foot view of the Linux boot process"|loc="Overview"}} (also called '''secondary bootloader''').{{Sfn|M. Tim Jones|2006|loc=, "Stage 1 boot loader"}} The second-stage bootloader will load the '''kernel image''' into memory, decompress and initialize it, and then pass control to this kernel image.{{Sfn|M. Tim Jones|2006|ps=, "Figure 1. The 20,000-foot view of the Linux boot process"|loc="Overview"}} The second-stage bootloader also performs several operation on the system such as system hardware check, mounting the root device, loading the necessary kernel modules, etc.{{Sfn|M. Tim Jones|2006|ps=, "Figure 1. The 20,000-foot view of the Linux boot process"|loc="Overview"}} Finally, the first user-space process (<code>init</code> process) starts, and other high-level system initializations are performed (which involve with startup scripts).{{Sfn|M. Tim Jones|2006|ps=, "Figure 1. The 20,000-foot view of the Linux boot process"|loc="Overview"}}

For each of these stages and components, there are different variations and approaches; for example, [[GNU GRUB|GRUB]], [[coreboot]] or [[Das U-Boot]] can be used as bootloaders (historical examples are [[LILO (boot loader)|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 [[Upstart (software)|Upstart]].

== System startup ==

'''System startup''' has different steps based on the hardware that Linux is being booted on, especially between embedded Linux and Linux PC.{{Sfn|M. Tim Jones|2006|loc=, "System startup"}} As mentioned earlier in the introduction part, during system startup stage, the [[BIOS|BIOS firmware]] is called. [[IBM PC compatible]] hardware is one architecture Linux is commonly used on; on these systems, the BIOS plays an important role. 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'''.{{Sfn|M. Tim Jones|2006|loc=, "System startup"}} 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.{{Sfn|M. Tim Jones|2006|loc=, "System startup"}} A hard disk to boot Linux stores the [[Master boot record|Master Boot Record]] ('''MBR'''), which contains the first-stage/primary bootloader in order to be loaded into RAM.{{Sfn|M. Tim Jones|2006|loc=, "System startup"}} IBM PC compatible replaces BIOS by UEFI. In [[UEFI]] systems, the Linux kernel can be executed directly by UEFI firmware via EFISTUB,<ref>{{Cite web |title=EFI stub kernel - Gentoo Wiki |url=https://wiki.gentoo.org/wiki/EFI_stub_kernel |access-date=2020-11-02 |website=wiki.gentoo.org}}</ref> but usually uses [[GRUB 2]] or [[Gummiboot (software)|systemd-boot]] as a bootloader.<ref name="Intel2000">{{cite web |last=Kinney |first=Michael |date=1 September 2000 |title=Solving BIOS Boot Issues with EFI |url=http://systems.cs.colorado.edu/Documentation/IntelDataSheets/xscalemagazine.pdf |url-status=dead |archive-url=https://web.archive.org/web/20070123141151/http://systems.cs.colorado.edu/Documentation/IntelDataSheets/xscalemagazine.pdf |archive-date=23 January 2007 |access-date=14 September 2010 |pages=47–50}}</ref><ref name="ElReg1">{{cite news |date=23 September 2011 |title=MS denies secure boot will exclude Linux |url=https://www.theregister.co.uk/2011/09/23/ms_denies_uefi_lock_in/ |access-date=24 September 2011 |publisher=The Register}}</ref>

The '''system startup stage on embedded Linux system''' starts by executing the firmware/program on the '''on-chip boot ROM''', which is stored on the storage device of the system like USB flash drive, SD card, eMMC, NAND flash, NOR flash, etc.{{Sfn|Alberto Liberal De Los Ríos|2017|loc=, "Linux Boot Process"|p=28}} The sequences of system startup in on-chip boot ROM varies by processors{{Sfn|Alberto Liberal De Los Ríos|2017|loc=, "Linux Boot Process"|p=28}} but all include '''hardware initialization''' and '''system hardware testing''' steps.{{Sfn|M. Tim Jones|2006|loc=, "System startup"}} For example in a system with an i.MX7D processor and a bootable device which stores the OS (including U-Boot, an external bootloader), the on-chip boot ROM sets up the [[DDR SDRAM|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.{{Sfn|Alberto Liberal De Los Ríos|2017|loc=, "Linux Boot Process"|p=28}} The on-chip boot ROM then loads the U-Boot into RAM for the bootloader stage.{{Sfn|Alberto Liberal De Los Ríos|2017|loc=, "Linux Boot Process"|p=29}}

== Bootloader stage ==

The '''first stage bootloader''', which is a part of the MBR, is a 512-byte image containing the vendor-specific '''program code''' and a '''partition table'''.{{Sfn|M. Tim Jones|2006|loc=, "Stage 1 boot loader"}} As mentioned earlier in the introduction part, the first stage bootloader will find and load the '''second stage bootloader'''.{{Sfn|M. Tim Jones|2006|loc=, "Stage 1 boot loader"}} It does this by searching in the partition table for an active partition.{{Sfn|M. Tim Jones|2006|loc=, "Stage 1 boot loader"}} After finding an active partition, first stage bootloader will keep scanning the remaining partitions in the table to ensure that they're all inactive.{{Sfn|M. Tim Jones|2006|loc=, "Stage 1 boot loader"}} After this step, the active partition's boot record is read into RAM and executed as the second stage bootloader.{{Sfn|M. Tim Jones|2006|loc=, "Stage 1 boot loader"}} The job of the second stage bootloader is to '''load the Linux kernel image into memory''', and '''optional initial RAM disk'''.{{Sfn|M. Tim Jones|2006|loc=, "Stage 2 boot loader"}} Kernel image isn't an executable kernel, but a [[Vmlinux|"compressed file" of the kernel]] instead, compressed into either [[Vmlinux|zImage or bzImage]] formats with [[zlib]].{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}}

In x86 PC, '''first- and second-stage bootloaders''' are combined into the [[GNU GRUB|GRand Unified Bootloader]] ('''GRUB'''), and formerly Linux Loader ([[LILO (bootloader)|LILO]]).{{Sfn|M. Tim Jones|2006|loc=, "Stage 2 boot loader"}} [[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 either by the [[BIOS]] from the [[Master boot record]] (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:

Line 28:

== Kernel ==

The kernel stage occurs after the bootloader stage. The [[Linux kernel]] handles all operating system processes, such as [[memory management]], task [[scheduling (computing)|scheduling]], [[I/O]], [[interprocess communication]], and overall system control. This is loaded in two stages &ndash; 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.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} It's worth noting that kernel image is '''self-decompressed''', which is a part of the kernel image's '''routine'''.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} For some platforms (like ARM 64-bit), kernel decompression has to be performed by the bootloader instead, like U-Boot.{{Sfn|Alberto Liberal De Los Ríos|2017|loc=, "Bootloader"|p=20}}

For details of those steps, take an example with [[i386]] microprocessor. When its bzImage is invoked, function <code>start()</code> (of <code>./arch/i386/boot/head.S</code>) is called to do some basic hardware setup then calls <code>startup_32()</code> (located in <code>./arch/i386/boot/compressed/head.S</code>).{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} <code>startup_32()</code>will do basic setup to environment (stack, etc.), clears the [[.bss|Block Started by Symbol]] (BSS) then invokes <code>decompress_kernel()</code> (located in <code>./arch/i386/boot/compressed/misc.c</code>) to decompressed the kernel.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} Kernel startup is then executed via a different <code>startup_32()</code> function located in <code>./arch/i386/kernel/head.S</code>.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} The startup function <code>startup_32()</code> for the kernel (also called the swapper or process 0) establishes [[memory management]] (paging tables and memory paging), detects the type of [[Central processing unit|CPU]] and any additional functionality such as [[floating point]] capabilities, and then switches to non-architecture specific Linux kernel functionality via a call to <code>start_kernel()</code> located in <code>./init/main.c</code>.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}}

{{Anchor|Early user space}}<code>start_kernel()</code>executes a wide range of initialization functions. It sets up [[interrupt handling]] ([[Interrupt request|IRQ]]s), further configures memory, mounts the [[initrd|initial RAM disk]] ("'''initrd'''") that was loaded previously as the temporary root file system during the bootloader stage.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} The initrd, which acts as a temporary root filesystem in RAM, allows the kernel to be fully booted and driver modules to be loaded directly from memory, without reliance upon other devices (e.g. a hard disk).{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} initrd contains the necessary modules needed to interface with peripherals,{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} e.g SATA driver, and support a large number of possible hardware configurations.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} This split of some drivers statically compiled into the kernel and other drivers loaded from initrd allows for a smaller kernel.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} [[initramfs]], also known as '''early user space''', has been available since version 2.5.46 of the Linux kernel,<ref>{{cite web |title=Initramfs arrives |url=https://lwn.net/Articles/14776/ |access-date=14 November 2011}}</ref> with the intent to replace as many functions as possible that previously the kernel would have performed during the startup process. Typical uses of early user space are to detect what [[device driver]]s are needed to load the main user space file system and load them from a [[temporary filesystem]]. Many distributions use [[dracut (software)|dracut]] to generate and maintain the initramfs image.

The root file system is later switched via a call to <code>pivot_root()</code> which unmounts the temporary root file system and replaces it with the use of the real one, once the latter is accessible.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} The memory used by the temporary root file system is then reclaimed.{{Clarify|date=March 2010}}