Content deleted Content added
Mention shim and preloader as potentially between the UEFI and bootlaoder/EFI stub. |
KMaster888 (talk | contribs) add or remove link to "reset vector" |
||
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]].
| |||