Booting process of Linux: Difference between revisions

Revision as of 18:32, 26 May 2024

Revision as of 04:30, 31 May 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 [[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 personal computer (PC), not only limited to Linux-distro PC, this firmware/program is called [[BIOS]], which 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 system, 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, 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 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"}} 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: