Bootloaders

A bootloader is a computer program that loads an operating system or some other system software for the computer after completion of the power-on self-tests (POST); it is the loader for the operating system itself. Within the hard reboot process, it runs after completion of the self-tests, then loads and runs the software. A bootloader is loaded into main memory from persistent memory, such as a hard disk drive or, in some older computers, from a medium such as punched cards, punched tape, or magnetic tape. The bootloader then loads and executes the processes that finalize the boot. Like POST processes, the bootloader code comes from a "hard-wired" and persistent location; if that location is too limited for some reason, that primary bootloader calls a second-stage bootloader or a secondary program loader.

On modern general purpose computers, the boot up process can take tens of seconds, and typically involves performing a power-on self-test, locating and initializing peripheral devices, and then finding, loading and starting an operating system. The process of hibernating or sleeping does not involve booting. Minimally, some embedded systems do not require a noticeable boot sequence to begin functioning and when turned on may simply run operational programs that are stored in ROM. All computing systems are state machines, and a reboot may be the only method to return to a designated zero-state from an unintended, locked state.

Boot is short for bootstrap or bootstrap load and derives from the phrase to pull oneself up by one's bootstraps. The usage calls attention to the requirement that, if most software is loaded onto a computer by other software already running on the computer, some mechanism must exist to load the initial software onto the computer. Early computers used a variety of ad-hoc methods to get a small program into memory to solve this problem. The invention of read-only memory (ROM) of various types solved this paradox by allowing computers to be shipped with a start up program that could not be erased. Growth in the capacity of ROM has allowed ever more elaborate start up procedures to be implemented.

Modern Bootloaders

When a computer is turned off, its software - including operating systems, application code, and data - remains stored on nonvolatile data storage devices such as hard disk drives, CDs, DVDs, flash memory cards (SD cards, for example), USB flash drives, and floppy disks. 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) along with a small amount of needed data, to access the nonvolatile device or devices from which the operating system programs and data can be loaded into RAM.

The small program that starts this sequence is known as a bootstrap loader, bootstrap or bootloader. This small program's only job is to load other data and programs which are then executed from RAM. Often, multiple-stage bootloaders are used, during which several programs of increasing complexity load one after the other in a process of chain loading.

Some 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 bootloader 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 bootloader 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 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.

bootloaders may face peculiar constraints, especially in size; for instance, on the IBM PC and compatibles, a boot sector should typically work in only 32 KB (later relaxed to 64 KB) of system memory and not use instructions not supported by the original 8088/8086 processors. The first stage of boot loaders (FSBL, first-stage bootloader) located on fixed disks and removable drives must fit into the first 446 bytes of the Master Boot Record in order to leave room for the default 64-byte partition table with four partition entries and the two-byte boot signature, which the BIOS requires for a proper bootloader - 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-bootloaders have to be supported as well in some environments. In floppy and superfloppy Volume Boot Records, up to 59 bytes are occupied for the Extended BIOS Parameter Block on FAT12 and FAT16 volumes since DOS 4.0, whereas the FAT32 EBPB introduced with DOS 7.1 requires even 71 bytes, leaving only 441 bytes for the bootloader 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 as consecutive sectors, conditions taken care of by the SYS command and slightly relaxed in later versions of DOS. The bootloader was then able to load the first three sectors of the file into memory, which happened to contain another embedded bootloader able to load the remainder of the file into memory. When they added LBA and FAT32 support, they even switched to a two-sector bootloader using 386 instructions. At the same time other vendors managed to squeeze much more functionality into a single boot sector without relaxing the original constraints on the only minimal available memory and processor support. For example, DR-DOS boot sectors are able to locate the boot file in the FAT12, FAT16 and FAT32 file system, and load it into memory as a whole via CHS or LBA, even if the file is not stored in a fixed location and in consecutive sectors.

Linux Bootloader

Linux startup process (Wiki)

The bootloader phase varies by computer architecture. Since the earlier phases are not specific to the operating system, the BIOS-based boot process for x86 and x86-64 architectures is considered to start when the master boot record (MBR) code is executed in real mode and the first-stage bootloader is loaded. In UEFI systems, a payload, such as the Linux kernel, can be executed directly. Thus no bootloader is necessary. Below is a summary of some popular bootloaders:

• LILO (LInux LOader) does not understand or parse filesystem layout. Instead, a configuration file (/etc/lilo.conf) 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 partition and kernel pathname for each, as well as customized options if needed, is then written together with bootloader code into the MBR bootsector. When this bootsector is read and given control by BIOS, LILO loads the menu code, draws it, and then uses stored values together with user input to calculate and load the Linux kernel or chain-load any other bootloader.
• The GRand Unified Bootloader, or GRUB, is a bootloader package. GRUB 1 (also known as GRUB Legacy) includes logic to read common file systems at run-time in order to access its configuration file. This gives GRUB 1 the 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.
• GRUB 2 differs from GRUB 1 by having two (optionally three) stages and being capable of automatic detection of various operating systems and automatic configuration. The first-stage loader (stage1) is loaded and executed either by the BIOS from the Master boot record (MBR) or by another bootloader from the partition boot sector. Its job is to discover and access various file systems that the configuration can be read from later. The optional, intermediate stage loader (stage1.5) is loaded and executed by the first-stage loader in case the second-stage loader is not contiguous or if the file-system or hardware requires special handling in order to access the second-stage loader. The second-stage loader (stage2) is loaded last and displays the GRUB startup menu that allows the user to choose an operating system or examine and edit startup parameters. After a menu entry is chosen and optional parameters are given, GRUB loads the kernel into memory and passes control to it. GRUB 2 is also capable of chain-loading of another bootloader.
• SYSLINUX/ISOLINUX is a bootloader that specializes in booting full Linux installations from FAT filesystems. It is often used for boot or rescue floppy discs, live USBs, and other lightweight boot systems. ISOLINUX is generally used by Linux live CDs and bootable install CDs.
• 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 devices. 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.

For a more complete list of available bootloaders, see the Comparison of bootloaders wiki page.

Determine Your Bootloader

To determine the Bootloader that is used on a particular system, use the following command:

sudo dd if=/dev/sda bs=512 count=1 2>/dev/null | strings | grep -Eoi 'grub|lilo|acronis|reboot'

Here is an example of the output:

[root@hdcentos etc]# sudo dd if=/dev/sda bs=512 count=1 2>/dev/null | strings | grep -Eoi 'grub|lilo|acronis|reboot'
GRUB

GRUB 1 or GRUB 2

In this example, GRUB is identified as being the bootloader. But this is not enough to identify if it is GRUB 1 or GRUB 2. If the GRUB signature was found, then run:

file -s /dev/sda

If the output is something like:

[root@hdcentos etc]# file -s /dev/sda
/dev/sda: x86 boot sector; GRand Unified Bootloader, stage1 version 0x3...

GRUB 1 is located on the master boot record (MBR).

If the output looks like this:

[root@hdcentos etc]# file -s /dev/sda
/dev/sda: x86 boot sector; partition 1: ID=0x83, active, starthead 32, startsect
or 2048, 1024000 sectors; partition 2: ID=0x8e, starthead 221, startsector 10260
48, 208689152 sectors, code offset 0x63

There is no mention of GRUB. Therefore, GRUB 2 can be assumed.