thumb|GNU GRUB, a popular free-software bootloader

thumb|right|[[Windows Boot Manager]]

thumb|[[rEFInd, a popular boot manager for EFI and UEFI systems]]

A bootloader, also spelled as boot loader or called bootstrap loader, is a computer program that is responsible for booting a computer and booting an operating system. If it also provides an interactive menu with multiple boot choices then it is often called a boot manager. 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.

They may also handle compression, cryptographic verification, and chain-loading of other bootloaders.

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.

Examples

IBM-compatible personal computers

Legacy BIOS

In x86 computers, after the BIOS executes Power-On Self Test, it executes the first-stage bootloader, which is a compact 512-byte program that resides in the master boot record (MBR). Running in 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 (later relaxed to 64 KiB) of system memory and only use instructions supported by the original 8088/8086 processors. The first stage of PC boot loaders (FSBL, first-stage boot loader) located on fixed disks and removable drives must fit into the first 446<!-- 512-4*16-2 --> bytes of the master boot record in order to leave room for the default 64-byte<!-- 4*16 --> partition table with four partition entries and the two-byte 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 disk signature (6 bytes), a disk timestamp (6 bytes), an Advanced Active Partition (18 bytes) or special multi-boot loaders<!-- like loader --> have to be supported as well in some environments.

In floppy and superfloppy volume boot records, up to 59<!-- 51+8 (ignoring the 3-byte-jump which can be counted as code) --> bytes are occupied for the extended BIOS parameter block (EBPB) on FAT12 and FAT16 volumes since DOS 4.0, whereas the 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,

In x86 computers, third-stage bootloaders include IO.SYS, NTLDR, BOOTMGR, and GRUB.

UEFI

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

IBM System/360 and successors

In IBM System/360 and successors, the LOAD operator control initiates a process called Initial Program Load (IPL), which

  1. Does a System reset
  2. Sends a Read IPL (IPL) channel command () to the selected device in order to read 24 bytes into locations 0-23 and causes the channel to begin fetching channel command words (CCWs) at location 8; the effect is as if the channel had fetched a CCW from location 0 with a length of 24, an address of 0 and the flags containing Command Chaining + Suppress Length Indication.
  3. At the completion of the operation, the system stores the I/O address in the halfword at location 2 and loads the PSW from location 0.

The operating systems for S/360 through z/Architecture reside on direct access storage devices (DASDs), e.g., disk, drum. For these devices, Read IPL does a seek to cylinder , head , and orients to record . For all supported operating systems, record 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 pointing to the first IPL program text instruction.

For OS/360 the IPL program does some initialization, relocates itself, locates the Nucleus, loads the nucleus and transfers to the Nucleus Initialization Program (NIP) at the end of the Nucleus.

Embedded and multi-stage boot loaders

<!-- 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” -->

Many embedded systems must boot immediately. For example, waiting a minute for a 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.

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

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, 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.

See also

  • Firmware
  • Comparison of bootloaders
  • Kernel

Notes

References

</references>

  • Bootloader - OSDev Wiki