Editing Bootloader (section)

==Examples==
===IBM-compatible personal computers===
====Legacy BIOS====
In [[x86]] computers, after the [[BIOS]] executes [[Power-On Self Test]], then a first-stage bootloader is a compact 512-byte program that resides in the [[master boot record]] (MBR) is executed. Running in [[real mode|16-bit real mode]] at address 0x7C00, it locates the second-stage bootloader. Its primary challenge lies in accomplishing these tasks within strict size constraints while handling potential hardware failures. The bootloader must navigate disk structures, often implementing [[FAT file system]] support, and manage the delicate transition from the BIOS startup state to a stable environment for the next boot stage.

First-stage MBR boot loaders may face peculiar constraints, especially in size; for instance, on the earlier IBM PC and compatibles, a boot sector should typically work with 510 bytes of code (or less) and in only 32&nbsp;KiB<ref name="Paul_1997_OD-A3"></ref><ref name="msakamoto-mbr">{{cite web|author-first=Masahiko|author-last=Sakamoto |title=Why BIOS loads MBR into 7C00h in x86?|date=13 May 2010|url=http://www.glamenv-septzen.net/en/view/6|website=glamenv-septzen.net|access-date=22 August 2012}}</ref> (later relaxed to 64 KiB<ref name="BBS_101">{{cite web|author1=Compaq computer corporation|author2=Phoenix technologies ltd|author3=Intel corporation|date=11 January 1996|title=BIOS boot specification 1.01|url=https://acpica.org/sites/acpica/files/specsbbs101.pdf|access-date=21 December 2017}}</ref>) of system memory and only use instructions supported by the original [[Intel 8088|8088]]/[[Intel 8086|8086]] processors. The first stage of PC boot loaders (FSBL, first-stage boot loader) located on [[Hard disk drive|fixed disk]]s and [[Disk enclosure|removable drive]]s must fit into the first 446<!-- 512-4*16-2 --> [[byte]]s of the [[master boot record]] in order to leave room for the default 64-byte<!-- 4*16 --> [[Disk partitioning#Partition table|partition table]] with four partition entries and the two-byte [[Master boot record#Programming considerations|boot signature]], which the BIOS requires for a proper boot loader &mdash; or even less, when additional features like more than four partition entries (up to 16 with 16 bytes each), a [[Master boot record#Disk identity|disk signature]] (6 bytes), a [[Master boot record#DISK TS|disk timestamp]] (6 bytes), an [[Master boot record#AAP|Advanced Active Partition]] (18 bytes) or special [[Multi-booting|multi-boot]] loaders<!-- like loader --> have to be supported as well in some environments.

In [[Floppy disk|floppy]] and [[Floppy disk variants#Superfloppy|superfloppy]] [[volume boot record]]s, up to 59<!-- 51+8 (ignoring the 3-byte-jump which can be counted as code) --> bytes are occupied for the [[BIOS parameter block|extended BIOS parameter block]] (EBPB) on [[File Allocation Table#FAT12|FAT12]] and [[File Allocation Table#Initial FAT16|FAT16]] volumes since DOS 4.0, whereas the [[File Allocation Table#FAT32|FAT32]] EBPB introduced with DOS 7.1 requires even 87 bytes, leaving only 423<!-- 512-87-2  (ignoring the 3-byte-jump which can be counted as code) --> bytes for the boot loader when assuming a sector size of 512 bytes. Microsoft boot sectors, therefore, traditionally imposed certain restrictions on the boot process. For example, the boot file had to be located at a fixed position in the root directory of the file system and stored within consecutive sectors,<ref name="Duncan_1988_MS-DOS_Encyclopedia" /><ref name="Chappell_1994_DOS-Internals" /> conditions taken care of by the <code>[[SYS (command)|SYS]]</code> command and slightly relaxed in later versions of DOS.<ref name="Chappell_1994_DOS-Internals" /><ref group="nb" name="NB_PC_DOS_Contiguous_files" /> The boot loader was then able to load the first three sectors of the file into memory, which happened to contain another embedded boot loader able to load the remainder of the file into memory.<ref name="Chappell_1994_DOS-Internals" /> When Microsoft added [[logical block addressing]] (LBA) and FAT32 support, they switched to a boot loader reaching over ''two'' physical sectors, using 386 instructions for size reasons. At the same time, other vendors managed to squeeze much more functionality into a single boot sector without relaxing the original constraints on only minimal available memory (32&nbsp;KiB) and processor support (8088/8086).<ref group="nb" name="NB_DR-DOS_707" /> For example, DR-DOS boot sectors are able to locate the boot file in the FAT12, FAT16<!-- since DR DOS 3.31 --> and FAT32<!-- DR-DOS 7.07 --> file systems, and load it into memory as a whole via [[cylinder-head-sector|CHS]] or LBA, even if the file is not stored in a fixed location and in consecutive sectors.<ref name="Rosch_1991_SYS" /><ref name="Paul_1997_OD-A3" /><ref name="Paul_2001" /><ref name="Paul_2002" /><ref name="Paul_2017" /><ref group="nb" name="NB_DR-DOS_File-size" /><ref group="nb" name="NB_DR-DOS_707" />

In x86 computers, second-stage bootloaders, such as [[partition boot record|PBR]], operate without the strict 512-byte limitation of their first-stage counterparts. They execute in a more sophisticated environment, typically ranging from 8KB to several megabytes in size. This expanded space allows implementation of complex features such as filesystem support, runtime configuration, and bootloader menu interfaces. 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, 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=15 May 2007}}</ref>

In x86 computers, third-stage bootloaders are include [[IO.SYS]], [[NTLDR]], [[BOOTMGR]] and [[GNU GRUB|GRUB]].

====UEFI====
UEFI (except for CSM boot) does not rely on boot sectors, it loads next-stage bootloader (such as [[BOOTMGR]] and [[GRUB2]]) from [[EFI System Partition]] directly.

===IBM System/360 and successors===
In [[IBM System/360]] and successors, the '''LOAD''' [[IBM System/360 architecture#Operator controls|operator control]] initiates a process called ''Initial Program Load'' (IPL),<ref group=nb>For [[z/Architecture]] the details are slightly different due to 64-bit addresses.</ref> which
#Does a ''System reset''
#Sends a ''Read IPL'' (IPL) channel command ({{base|02|16}}) to the selected device in order to read 24 bytes into locations 0-23 and causes the channel to begin fetching CCWs at location 8; the effect is as if the channel had fetched a CCW from location 8 with a length of 24, an address of 0 and the flags containing Command Chaining + Suppress Length Indication.
#Stores the I/O address in the halfword at location 2
#Loads the PSW from location 0.

The operating systems for S/360 through [[z/Architecture]] reside on [[direct access storage device]]s (DASDs), e.g., disk, drum. For these devices, ''Read IPL'' does a seek to cylinder {{base|0000|16}}, head {{base|0000|16}}, and orients to record {{base|01|16}}. For all supported operating systems, record {{base|01|16}} contains a ''Read Data'' CCW to read a ''bootstrap record'' and a ''Transfer In Channel'' (TIC) CCW to the bootstrap. The channel program in the bootstrap reads the IPL program text into location 0, beginning with a PSW pointingto the first IPL program text instruction.

For [[OS/360]]<ref group=nb>The process has more complexity for successors to OS/360, and has some differences for other OS families.</ref><ref>{{cite book
 | title       = OS Release 21 - IBM System/360 Operating System - Initial Program Loader and Nucleus Initialization Program - Program Number 360S-CI-535
 | id          = GY28-6661-5
 | date        = March 1972
 | edition     = Sixth
 | section     = THE INITIAL PROGRAM LOADER
 | section-url = http://bitsavers.org/pdf/ibm/360/os/R21.0_Mar72/plm/GY28-6661-5_Inital_Program_Loader_and_Nucleus_Initialization_Program_Rel21_PLM_Mar72.pdf#page=11
 | pages       = 3-10
 | series      = Program Logic
 | url         = http://bitsavers.org/pdf/ibm/360/os/R21.0_Mar72/plm/GY28-6661-5_Inital_Program_Loader_and_Nucleus_Initialization_Program_Rel21_PLM_Mar72.pdf
 | access-date = April 16, 2023
 }}
</ref> the IPL program does some initialization, relocates itself, locates the ''Nucleus'',<ref group=nb>The nucleus contains OS components that must always be present in processor storage. Most of the code is privileged, but there are also subroutines for use by application programs.</ref><ref group=nb>The Nucleus resides in member '''IEANUC0x''' of '''SYS1.NUCLEUS''' on the IPL volume, where ''x'' is normally 1 but may be changed by the operator.</ref> loads the nucleus and transfers to the ''Nucleus Initialization Program'' (NIP) at the end of the Nucleus.