Editing Booting (section)

== Modern boot loaders<span class="anchor" id="Boot-loader"></span> ==
{{See also|Comparison of boot loaders|Bootloader}}<!--

Note to editors: this section (in the [[Booting]] article) contains much of the same text as the [[Bootloader]] article. Changes to one article will _not_ automatically update the text in the other, as the following sub-sections are not currently ‘transcluded’ from one article to the other.

See [[Help:Transclusion]] for more information.

-->
When a computer is turned off, its software{{mdashb}}including operating systems, application code, and data{{mdashb}}remains stored on [[non-volatile memory]]. When the computer is powered on, it typically does not have an operating system or its loader in [[random-access memory]] (RAM). The computer first executes a relatively small program stored in [[read-only memory]] (ROM, and later EEPROM, [[NOR flash]]) which support [[execute in place]], to initialize CPU and motherboard, to initialize the memory (especially on x86 systems), to initialize and access the storage (usually a block-addressed device, e.g. [[hard disk drive]], [[NAND flash]], [[solid-state drive]]) from which the operating system programs and data can be loaded into RAM, and to initialize other I/O devices.

The small program that starts this sequence is known as a ''bootstrap loader'', ''bootstrap'' or ''boot loader''. Often, multiple-stage boot loaders are used, during which several programs of increasing complexity load one after the other in a process of [[chain loading]].

Some earlier computer systems, upon receiving a boot signal from a human operator or a peripheral device, may load a very small number of fixed instructions into memory at a specific location, initialize at least one CPU, and then point the CPU to the instructions and start their execution. These instructions typically start an input operation from some peripheral device (which may be switch-selectable by the operator). Other systems may send hardware commands directly to peripheral devices or I/O controllers that cause an extremely simple input operation (such as "read sector zero of the system device into memory starting at location 1000") to be carried out, effectively loading a small number of boot loader instructions into memory; a completion signal from the I/O device may then be used to start execution of the instructions by the CPU.

Smaller computers often use less flexible but more automatic boot loader mechanisms to ensure that the computer starts quickly and with a predetermined software configuration. In many desktop computers, for example, the bootstrapping process begins with the CPU executing software contained in ROM (for example, the BIOS of an [[IBM PC]]) at a predefined address (some CPUs, including the Intel [[Intel 8086|x86 series]] are designed to execute this software after reset without outside help). This software contains rudimentary functionality to search for devices eligible to participate in booting, and load a small program from a special section (most commonly the [[boot sector]]) of the most promising device, typically starting at a fixed [[entry point]] such as the start of the sector.

Boot loaders may face peculiar constraints, especially in size; for instance, on the IBM PC and compatibles, the boot code must fit in the [[Master Boot Record]] (MBR) and the [[Partition Boot Record]] (PBR), which in turn are limited to a single sector; on the [[IBM System/360]], the size is limited by the IPL medium, e.g., [[Punched card|card]] size, track size.

On systems with those constraints, the first program loaded into RAM may not be sufficiently large to load the operating system and, instead, must load another, larger program. The first program loaded into RAM is called a first-stage boot loader, and the program it loads is called a second-stage boot loader. On many embedded CPUs, the CPU built-in boot ROM, sometimes called the zero-stage boot loader,<ref>{{cite web |url=https://crvf2019.github.io/pdf/43.pdf |title=An Introduction to RISC-V Boot flow |access-date=2024-09-04}}</ref> can find and load first-stage boot loaders.

=== First-stage boot loaders ===
Examples of first-stage (hardware initialization stage) boot loaders include BIOS, UEFI, [[coreboot]], [[Libreboot]] and [[Das U-Boot]]. On the IBM PC, the boot loader in the [[Master Boot Record]] (MBR) and the [[Partition Boot Record]] (PBR) was coded to require at least 32&nbsp;KB<ref name="Paul_1997_OD-A3"/><ref name="msakamoto-mbr">{{cite web |author-first=Masahiko |author-last=Sakamoto |title=Why BIOS loads MBR into 7C00h in x86? |date=2010-05-13 |url=http://www.glamenv-septzen.net/en/view/6 |website=Glamenv-Septzen.net |access-date=2012-08-22 |archive-date=2017-08-24 |archive-url=https://web.archive.org/web/20170824002951/https://www.glamenv-septzen.net/en/view/6 |url-status=live}}</ref> (later expanded to 64&nbsp;KB<ref name="BBS_101">{{cite web |author1=Compaq Computer Corporation |author2=Phoenix Technologies Ltd |author3=Intel Corporation |date=1996-01-11 |title=BIOS Boot Specification 1.01 |url=https://acpica.org/sites/acpica/files/specsbbs101.pdf |archive-url=https://ghostarchive.org/archive/20221009/https://acpica.org/sites/acpica/files/specsbbs101.pdf |archive-date=2022-10-09 |url-status=live |access-date=2017-12-21}}</ref>) of system memory and only use instructions supported by the original [[8088]]/[[8086]] processors.

=== Second-stage boot loaders ===
{{Anchor|SECOND-STAGE}}
Second-stage (OS initialization stage) boot loaders, such as shim,<ref>{{cite web |last1=Red Hat Bootloader Team |title=UEFI shim loader |url=https://github.com/rhboot/shim |website=GitHub |access-date=28 October 2023}}</ref> [[GNU GRUB]], [[rEFInd]], [[BOOTMGR]], [[Syslinux]], and [[NTLDR]], are not themselves operating systems, but are able to load an operating system properly and transfer execution to it; the operating system subsequently initializes itself and may load extra [[device driver]]s. The second-stage boot loader does not need drivers for its own operation, but may instead use generic storage access methods provided by system firmware such as the BIOS, UEFI or [[Open Firmware]], though typically with restricted hardware functionality and lower performance.<ref>{{cite book |publisher=Microsoft |title=Windows NT Server Resource Kit |chapter=Chapter 6 - Troubleshooting Startup and Disk Problems |chapter-url=http://www.microsoft.com/resources/documentation/windowsnt/4/server/reskit/en-us/resguide/troubles.mspx?mfr=true |archive-url=https://web.archive.org/web/20070515104908/http://www.microsoft.com/resources/documentation/windowsnt/4/server/reskit/en-us/resguide/troubles.mspx?mfr=true |archive-date=2007-05-15}}</ref>

Many boot loaders (like GNU GRUB, rEFInd, Windows's BOOTMGR, Syslinux, and Windows NT/2000/XP's NTLDR) can be configured to give the user multiple booting choices. These choices can include different operating systems (for [[dual boot|dual or multi-booting]] from different partitions or drives), different versions of the same operating system (in case a new version has unexpected problems), different operating system loading options (e.g., booting into a rescue or [[safe mode]]), and some standalone programs that can function without an operating system, such as memory testers (e.g., [[memtest86+]]), a basic shell (as in GNU GRUB), or even games (see [[List of PC Booter games]]).<ref>{{cite web |url=http://www.coreboot.org/Tint |title=Tint |publisher=coreboot |access-date=2010-11-20 |archive-date=2010-12-28 |archive-url=https://web.archive.org/web/20101228053937/http://www.coreboot.org/Tint |url-status=live}}</ref> Some boot loaders can also load other boot loaders; for example, GRUB loads BOOTMGR instead of loading Windows directly. Usually a default choice is preselected with a time delay during which a user can press a key to change the choice; after this delay, the default choice is automatically run so normal booting can occur without interaction.

The boot process can be considered complete when the computer is ready to interact with the user, or the operating system is capable of running system programs or application programs.

=== Embedded and multi-stage boot loaders ===
{{Anchor|Embedded|MULTI-STAGE}}<!-- Note to future editors: consider breaking this into two sections if the contents expand to more than one paragraph.

Possible alternate section title?: “Embedded and complex systems”

See also the similar text contents at [[Bootloader#Embedded]]

-->
Many [[embedded system]]s must boot immediately. For example, waiting a minute for a [[Television set|digital television]] or a [[GPS navigation device]] to start is generally unacceptable. Therefore, such devices have software systems in ROM or [[flash memory]] so the device can begin functioning immediately; little or no loading is necessary, because the loading can be precomputed and stored on the ROM when the device is made.{{citation needed|date=September 2023}}

Large and complex systems may have boot procedures that proceed in multiple phases until finally the operating system and other programs are loaded and ready to execute. Because operating systems are designed as if they never start or stop, a boot loader might load the operating system, configure itself as a mere process within that system, and then irrevocably transfer control to the operating system. The boot loader then terminates normally as any other process would.

=== Network booting ===
{{Main|Network booting}}

Most computers are also capable of booting over a [[computer network]]. In this scenario, the operating system is stored on the disk of a [[server (computing)|server]], and certain parts of it are transferred to the client using a simple protocol such as the [[Trivial File Transfer Protocol]] (TFTP). After these parts have been transferred, the operating system takes over the control of the booting process.

As with the second-stage boot loader, network booting begins by using generic network access methods provided by the network interface's boot ROM, which typically contains a [[Preboot Execution Environment]] (PXE) image. No drivers are required, but the system functionality is limited until the operating system kernel and drivers are transferred and started. As a result, once the ROM-based booting has completed it is entirely possible to network boot into an operating system that itself does not have the ability to use the network interface.