Content deleted Content added
Toughpigs please do not un-bold the texts |
→Bootloader stage: The MBR boot sector (MBR boot code) is only used on x86 BIOS systems. However, the MBR partition table can be used on modern UEFI PCs, as well as non-x86 embedded devices (while the boot loader is not MBR boot sector). Tags: Mobile edit Mobile web edit |
||
| (35 intermediate revisions by 21 users not shown) | |||
Line 1:
{{Short description|Multi-stage initialisation process of operating system}}
{{Technical|date=August 2025}}
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"}}▼
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,{{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"}}
▲
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]].▼
▲For each of these stages and components, there are different variations and approaches; for example, [[GNU GRUB|GRUB]], [[systemd-boot]], [[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.{{Sfn|M. Tim Jones|2006|loc=, "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>▼
[[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.{{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"}}
▲
If [[UEFI#Secure_Boot|UEFI Secure Boot]] is supported, a "shim" or "Preloader" is often booted by the UEFI before the bootloader or EFI-stub-bearing kernel.<ref>{{Cite web |title=Using a Signed Bootloader - Arch Wiki |url=https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Using_a_signed_boot_loader |access-date=2024-12-05 |website=wiki.archlinux.org}}</ref> Even if [[UEFI#Secure_Boot|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
== Bootloader stage ==
In x86 PC,
Beside GRUB, there are some more popular bootloaders:
Line 24 ⟶ 35:
* [[LILO (boot loader)|LILO]] does not understand or parse filesystem layout. Instead, a configuration file (<code>/etc/lilo.conf</code>) 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 [[Disk partitioning|partition]] and [[Kernel (computer science)|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 loading|chain-load]] any other [[Booting#Boot-loader|boot-loader]].
* GRUB 1 includes logic to read common file systems at run-time in order to access its configuration file.<ref name="redhat_startup">{{cite web|url=http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-boot-init-shutdown-process.html |archive-url=https://web.archive.org/web/20080830065326/http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-boot-init-shutdown-process.html |url-status=dead |archive-date=2008-08-30 |title=Product Documentation |publisher=Redhat.com |date=2013-09-30 |access-date=2014-01-22}}</ref> 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.<ref name="redhat_lilo">{{cite web|url=http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-grub-lilo.html |title=Product Documentation |publisher=Redhat.com |date=2013-09-30 |access-date=2014-01-22}}</ref>
* [[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 device]]s. 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 (computing)|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.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}}
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
{{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 |last1=Corbet |first1=Jonathan |title=Initramfs arrives |date=6 November 2002 |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}}
Line 53 ⟶ 64:
* [[systemd]] is a modern alternative to SysV init. Like init, systemd is a daemon that manages other daemons. All daemons, including systemd, are [[background process]]es. [[Lennart Poettering]] and [[Kay Sievers]], software engineers that initially developed systemd,<ref>{{cite web |title=systemd README |url=http://cgit.freedesktop.org/systemd/systemd/tree/README |accessdate=2012-09-09 |website=freedesktop.org}}</ref> sought to surpass the efficiency of the init daemon in several ways. They wanted to improve the software framework for expressing dependencies, to allow more processing to be done in [[Parallel computing|parallel]] during system booting, and to reduce the [[computational overhead]] of the [[Shell (computing)|shell]]. Systemd's initialization instructions for each daemon are recorded in a declarative configuration file rather than a shell script. For [[inter-process communication]], systemd makes [[Unix ___domain socket]]s and [[D-Bus]] available to the running daemons. Systemd is also capable of aggressive parallelization.
== See also ==
{{Portal|Linux}}
* [[SYSLINUX]]
* [[Booting process of Android devices]]
* [[Booting process of macOS]]
* [[Booting process of Windows]]
Line 67 ⟶ 81:
== External links ==
* [[wikiversity:Linux/Reading_the_Linux_Kernel_Sources|Reading the Linux Kernel Sources]], Wikiversity
* {{webarchive |url=https://web.archive.org/web/20091023232400/http://axiom.anu.edu.au/~okeefe/p2b/power2bash/power2bash.html |date=Oct 23, 2009 |title=Greg O'Keefe - From Power Up To Bash Prompt }}
* [https://web.archive.org/web/20121105224739/http://www.bootchart.org/ Bootchart: Boot Process Performance Visualization]
| |||