Here we can see “The BIOS/MBR Boot Process”
Standard (“IBM-compatible”) desktop PCs and laptops all power on and start-up using one of two methods: the traditional BIOS-MBR method and the newer UEFI-GPT method, which is used by the latest versions of Windows, Linux, and Mac OS X on newer PCs, laptops, and tablets, regardless of the computer or operating system. This page covers the basics and specifics of the BIOS, MBR, and bootsector and how typical BIOS PCs load an operating system.
Unofficially, this article has been labelled Part one of everything you’ve ever wanted to know about how your computer boots.
The BIOS/MBR Boot Process in Detail
The boot sequence for all standard computers and operating systems are represented in the diagram below:
As you can see, the boot process is divided into several primary components, each of which is its subsystem with various settings and modifications. The rules they follow and the method by which they work may vary based on your hardware and operating system, but the rules they follow and their work process remain consistent.
The Boot Process’s Components
The BIOS is the computer’s operating system
The BIOS is the first place where hardware and software collide, and all the boot magic begins. The BIOS code is baked into your PC’s motherboard, usually stored on an EEPROM 1 chip, and is highly hardware-specific. The BIOS is the lowest level of software that communicates with and controls the hardware.2 It is the interface via which the bootloader and operating system kernel communicate with and control the hardware. The operating system can trigger the BIOS to read and write to the disk and interface with other hardware components using specified calls to the BIOS (“interrupts” in computer lingo).
When you turn on your computer for the first time, a lot happens. Debouncing circuits accept your push of the power button and trigger a switch that activates the power supply and distributes current from the PSU to the motherboard and, primarily through it, to all the various components of your PC. Each component is powered up and brought online to its initial state as it gets life-giving electricity. Simpler components, such as RAM and the power supply, have their startup routines. Overall functionality is hardwired into them as a series of logic circuits (AND/NAND and OR/NOR gates). In contrast, more complicated parts, such as the video card, have their microcontrollers that act as mini-CPUs, controlling the hardware and interacting with the rest of your PC to delegate and oversee the work.
The POST Methodology
ONCE YOUR PC IS TURNED ON, the BIOS starts working as part of the POST (Power-On Self-Test) procedure. It connects all of your PC’s parts and interfaces with them as needed, such as setting up your video display to accept basic VGA and display it on the screen, initializing memory banks, and giving your CPU access to all of the hardware. It looks for attached devices on the IO buses and recognizes and maps access to the hard disks you’ve connected to your PC. Newer motherboard BIOSes are intelligent enough to recognize and identify USB devices like external drives and USB mice, allowing you to boot from USB sticks and use your mouse in legacy applications.
When possible, fast tests are performed during the POST phase, and faults are caused by incompatible hardware, disconnected devices, or failed components. Several error messages, such as “keyboard error or no keyboard present” or warnings regarding mismatched/unrecognized memory, are caused by the BIOS. At this point, the BIOS has finished most of its work and is almost ready to proceed to the next stage of the boot process. The only thing left is to execute “Add-On ROMs”. Some motherboard hardware may require user intervention to complete its initialization. The BIOS hands off control of the entire PC to software procedures programmed into hardware such as video cards or RAID controllers. They take over control of the computer and its display, allowing you to do things like setting up RAID arrays and modifying display settings before the computer has fully booted up. When they’re done, they return control of the computer to the BIOS, and the computer enters a basic, workable condition, ready to start.
BIOS Boot Handoff is a term that refers to the process of switching from one
After configuring your PC’s basic input and output devices, the BIOS now enters the last stages of its control over your machine. Normally, you’ll be given the option to rapidly press a key to enter the BIOS setup, where you may adjust hardware settings and manage how your PC boots. If you leave the BIOS alone, it will begin the process of “booting” your computer with the default settings.
We already noted that detecting and mapping attached hard disks is a key component of the BIOS’ job. The BIOS will now load a very small program from the first hard disk into memory and order the CPU to execute its contents, giving control of the computer over to whatever is on the hard drive and concluding its active role in loading your PC. This hard drive is referred to as “the boot device,” “starting disk,” or “drive 0,” and it is typically selected or specified in the BIOS configuration.
The device is used to start the computer
The handoff sequence is the same whether the BIOS is configured to boot from a local hard disk or a detachable USB stick. The BIOS loads the first 512 bytes from the hard disk of the selected boot device once the BIOS POST and AddOn ROM procedures have been completed — these 512 bytes are known as the MBR, or Master Boot Record.
The Original Boot Record (MBR)
On BIOS-based devices, the MBR is the first and most significant component on the software side of the boot mechanism. The MBR is found on every hard disk and contains several crucial bits of information.
The Table of Partitions
First and foremost, the MBR contains a partition table, an index of up to four partitions that exist on the same disk, essentially a table of contents. Without it (like on floppy disks), the entire disk could only contain one partition, which means you can’t have various filesystems on the same drive, which means you couldn’t, for example, install Linux and Windows on the same disk.
Bootstrap is a framework for creating websites
Second, the MBR includes a crucial piece of code known as the “bootstrap code.” The first 4403 bytes of these 512 bytes can be anything; the BIOS will load it and execute its contents as-is, initiating the bootloader mechanism. Four hundred forty bytes is a small amount of data. How little is it? To put things in perspective, 440 bytes is only 0.3 percent of the size of an old 1.44 MiB floppy disk – barely enough to fit any useful code – and way, way too little to call up the operating system kernel from the disk.
Given how little the MBR’s bootstrap code portion is, the only practical function it can accomplish is to look up and load another file from the disk to execute the actual boot process. As a result, the bootstrap code is frequently referred to as a “stage one bootloader.” The exact location where the bootstrap code looks for the “stage 2 bootloader” varies by the operating system. Still, on Windows, the stage 1 bootloader will look in the MBR’s partition table for a partition marked as “active,” which is MBR-speak for “bootable,” indicating that the partition’s beginning sectors (also known as its “bootsector”) contain the next portion of the boot code. Only one partition can be identified as active at a time on a properly built MBR disk. 4
So the task of the MBR’s bootstrap code section is quite straightforward: lookup the current partition in the partition table, load that code into memory, and have the CPU execute it as the next link in the boot chain. Depending on the OS you’re loading, it might look up a hard-coded partition instead of the active partition (e.g. always load the 3rd partition’s bootsector), and the offset of the boot code within the partition bootsector might change (e.g. instead of being the first 2 KiB of the partition, it might be the second KiB or 6 KiB starting from the 2nd multiple of the current phase of the moon) – but the basic concept remains the same. However, the MBR nearly always loads the first sector of the active partition for legacy compatibility concerns, which is only another 512 bytes.
Signature Boots
The boot signature is the final two bytes of the 512-byte MBR on IBM-compatible PCs (essentially everything) and is used by the BIOS to evaluate whether the selected boot drive is indeed bootable or not. The last two bytes of the MBR of a disk with proper bootstrap code should always be 0x55 0xAA. 5 The BIOS will assume that the disk is not bootable and is not a viable boot option if the last two bytes of the MBR do not equal 0x55 and 0xAA, respectively. In this situation, it will fall back to the next device in the boot order list (as configured in the BIOS setup). If the BIOS has the USB stick as the first boot device and the local hard drive as the second, the BIOS will bypass the USB stick if it does not have the correct boot signature and instead try to load from the local disk. The BIOS will display an error such as “No boot device is available” or “Reboot and select proper boot device” if no disk in the boot device list contains the right 0x55 0xAA boot signature.
The Boot Sector of the Partition
As previously stated, the MBR bootstrap code will normally load a series of bytes from the beginning of the current partition. The actual layout of a partition varies depending on the filesystem used to create or format it.
The specific layout of the partition will, once again, vary depending on the OS and filesystem. However, this is a close representation of what you’ll typically see:
- The assembly6 equivalent of a goto command is a single JMP (jump) instruction.
- The filesystem header will contain information that is unique to and critical to the filesystem.
- The next stage of the bootloader procedure is contained in another bootstrap code segment.
- The 0x55 0xAA boot signature we saw earlier in the MBR is an end-of-sector marker.
All of this is usually crammed into the partition’s first sector, which is typically only 512 bytes large and can’t hold much data or instructions. The bootstrap code can take advantage of expanded BIOS functionality to read and execute more than 512 bytes on current filesystems for newer operating systems, but the core procedures remain the same:
- The MBR writes the first 512 bytes of the active partition to memory and tells the CPU to run them.
- The partition bootsector’s first (three) bytes include a single JMP instruction, instructing the CPU to skip xx bytes and proceed to the next stage of the Bootloader.
- Following the JMP instruction, the CPU looks to the beginning of the partition bootsector’s bootstrap code and executes it.
The partition’s bootstrap code isn’t the end of the road; it’s just a step in the right direction. The code in the partition bootsector usually concludes with another JMP instruction ordering the CPU to go to the next sector in the partition, which is commonly set aside for the remainder of the partition code, due to how little space is allowed for the bootstrap code in the partition bootsector. This can be multiple sectors long or whatever length is required to fit this bootloader level, depending on the filesystem.
The Bootloader for the second stage
The second stage of the Bootloader, which is stored in the partition bootsector in the bootstrap section and may continue beyond it, performs the next step in the bootloader process: it looks up a file stored on the partition itself (as a regular file). It instructs the CPU to execute its contents to start the final part of the boot process.
The next stage in the boot process is not placed at a designated offset inside the partition (i.e. the bootstrap code can’t merely tell the CPU to JMP to address 0xABC and execute the boot file from there) – it’s a normal file stored amongst other normal files in the filesystem on the disk.
This much more complicated bootstrap code must read the table-of-contents for the filesystem on the partition.
7 Older versions of file systems’ second-stage bootloaders typically imposed difficult constraints on the bootloader files they needed to load, such as requiring them to exist in the first few kilobytes of the partition or preventing them from loading non-contiguously allocated files. This file is the final piece of the bootloader puzzle. Its size and contents are normally unrestricted, allowing it to be as vast and complex as it needs to load the operating system kernel from disk and control the PC to the OS.
The Bootloader
The final pieces of the boot loading procedure are the bootloader files on the disk. When people talk about bootloaders and boot files, they usually talk to the last and most important phase in the boot process.
The actual logic involved in determining which operating system to load, where to load it from, which parameters/options to pass on to it, and completing any interactions with the user that might be available, the actual process of starting the PC from the BIOS to the bootstrap code in the MBR and from the MBR to the bootstrap code in the partition bootsector, and from there to the executable boot files on the active partition,
Files for Boot Configuration
While the executable bootloader files may theoretically contain hard-coded information about the operating systems to be loaded from disk, this would be extremely inefficient. As a result, practically all bootloaders segregate the Bootloader itself from the configuration file or database containing information on the operating system(s) to load. All of the major bootloaders listed below support “dual-booting” or “multi-booting,” which is the process of loading several operating systems.
Bootloaders that are widely used
As previously stated, there are numerous bootloaders available. Each operating system has its Bootloader, which is responsible for reading the filesystem and locating the kernel required for the OS to function. For some of the more prevalent operating systems, here are some of the more popular bootloaders — along with their necessary configuration files:
The default bootloader for each of the common operating systems is different. The NTLDR bootloader is used by Windows NT, 2000, XP, and Windows Server 2000 and 2003. The BOOTMGR bootloader was introduced in Windows Vista and is now utilized by Windows Vista, 7, 8, and 10 and Windows Server 2008 and 2012. While there have been a variety of bootloaders for Linux throughout the years, the two most popular bootloaders were Lilo and GRUB. Still, most Linux distributions today use the all-powerful GRUB2 Bootloader.
NTLDR
NTLDR is a legacy Windows bootloader that was initially introduced in Windows NT (thus the “NT” in “NTLDR,” which stands for “NT Loader”) and is still supported by Windows NT, Windows 2000, Windows XP, and Windows Server 2003.
NTLDR saves its boot configuration in a simple text file named BOOT.INI, located in the current partition’s root directory (often C:\Boot.ini). Once NTLDR has been loaded and processed by the second-stage Bootloader, it runs a helper software called NTDETECT.COM, recognizing the hardware and creating a system index. The associated articles in our knowledgebase have further information about NTLDR, BOOT.INI, and NTDETECT.COM.
BOOTMGR
BOOTMGR is a newer version of the Microsoft Windows bootloader that was first released in Windows Vista beta versions (then Windows Codename Longhorn). Windows Vista, Windows 7, Windows 8, Windows 8.1, and Windows 10, as well as Windows Server 2008 and Windows Server 2012, all use it.
In comparison to NTLDR, BOOTMGR was a big deviation. It’s a self-contained bootloader with a lot more features, built to work with newer features in modern operating systems and to support EFI and GPT (albeit only some versions of BOOTMGR enable booting Windows from a GPT drive or in a UEFI/EFI setup). BOOTMGR, unlike NTLDR, saves its configuration in a file called the BCD, which stands for Boot Configuration Database. The BCD file, unlike BOOT.INI, is a binary database that can’t be read or altered by hand. 8 To read and alter the list of operating systems, special command-line programs like bcdedit.exe and user-friendly GUI utilities like EasyBCD must be used.
GRUB was the most widely used Bootloader for Linux in the 1990s and early 2000s. It was designed to load Linux and any operating system with a kernel that implemented the open multiboot specification. Menu.lst or grub.lst was the name of the GRUB configuration file, which included a whitespace-formatted list of operating systems. It was located in the /boot/ or /boot/grub/ directory. Because these settings might be altered by recompiling GRUB with different parameters, this file was named differently in different Linux distributions and stored in separate directories.
GRUB 2
While GRUB eventually triumphed over Lilo and eLilo, it was later superseded by GRUB 2 in 2002, and the previous GRUB was called “Legacy GRUB.” Although the current edition of the GRUB bootloader is now officially called GRUB, the previous GRUB has been relegated to the name “Legacy GRUB,” you’ll find that most materials online refer to the newer incarnation of the GRUB bootloader as GRUB 2.
GRUB 2 is a flexible, powerful bootloader that functions more like an operating system than a bootloader. It offers custom plugins (“modules”) to add more functionality and handle complex boot procedures, and it can load dozens of different operating systems.
The real bootloader file for GRUB 2 is called core.img and is not called GRUB2. Unlike Legacy GRUB 2 configuration files, the GRUB is more script than a typical configuration file. The grub.cfg file, which is generally found on the boot disk at /boot/grub/grub.cfg, looks like a shell script and supports sophisticated concepts like functions. Modules, usually found in a subdirectory of the /boot/grub/ directory, supplement the main functionality of GRUB 2.
The Start-Up Procedure
As previously stated, this boot process step is a little more involved than the others, owing to the added complexity of accessing the filesystem. To correctly load the intended operating system from the correct partition and give any additional files or data that may be required, the Bootloader must additionally gather information about the underlying machine hardware (either via the BIOS or on its own). It must also read its configuration file from a regular file on the filesystem of the boot partition. Therefore it must have full read support for whatever filesystem it is on.
- Access the filesystem for the first time
The Bootloader must first load and run the virtual filesystem “drivers” that allow it to read, at the very least, the filesystem it is placed on before anything further can happen. Because it can’t read the filesystem before this, the code that provides this functionality must be compiled into the Bootloader’s core file.
- Open the configuration file and read it (s)
With filesystem support loaded, the Bootloader may now read the list of operating systems from the disk and prepare it for display if several operating systems are specified.
- Supporting modules should be loaded and run
The Bootloader now loads any supporting modules or auxiliary programs (such as NTDETECT.COM) from the disk for bootloaders that aren’t entirely self-contained (NTLDR and GRUB 2). The list of modules to load can be supplied in the configuration file that was just read or hard-coded/compiled directly into the Bootloader. Normally, each module is executed in the order in which it is found and loaded from the disk.
- The boot menu will appear
The Bootloader can now display what is generally referred to as the boot menu on the screen, as long as it has all of the necessary configurations. If the computer has numerous operating systems installed, the user can explore a list of operating systems and choose one to launch from the boot menu. Certain bootloaders additionally allow you to set run-time parameters, such as whether the operating system should be loaded in safe mode.
- Load the operating system kernel
The Bootloader moves on to the last and final stage of the boot process once the user’s selection has been recorded. The Bootloader will load the kernel image from the path supplied in the configuration file (with the help of any submodules, if necessary) into memory, depending on the OS and the type of kernel. The CPU is then instructed to JMP to a specific point inside the freshly loaded kernel and start executing from there.
Conclusion
Thus concludes a long trip that began with a button press and ended with an operating system’s kernel loaded into memory and executed. The bootloader process is far more subtle and complicated than most people know. It has been developed and evolved to work reasonably uniformly across many platforms and operating systems.
The Bootloader’s constituent components are, for the most part, self-contained and self-sufficient. They may be replaced separately without impacting the entire system, allowing you to install disks and boot from other devices without disrupting existing setups and operating systems. It also implies that instead of having a single piece of hardware/software to install, setup, maintain, and debug, you’re left with a complex and usually quite fragile chain with several points prone to failure. A boot process is a well-oiled machine when it’s running well, but when calamity hits, it may be a challenging process to grasp and debug.
User Questions:
1. What is MBR, and how does it affect the booting process?
The Master Boot Record (MBR) is the initial sector of any hard disk or diskette that identifies how and where an operating system is located to be booted (loaded) into the computer’s primary storage or random access memory.
2. Is the MBR format compatible with BIOS?
Legacy BIOS systems can only boot from MBR partition tables (there are exceptions, but this is the general norm), and the MBR specification can only address up to 2TiB of disk space. Hence a BIOS system can only boot from disks with a capacity of 2TiB or less.
3. What does MBR stand for?
“Master Boot Record” is the abbreviation for “Master Boot Record.” A master boot record (MBR) is a short area of a hard disk or another storage device that stores information about the disk. The master boot record was originally used by PC-DOS compatible computers in 1983, and for more than two decades, it was the usual way to format DOS disks.
4. ELI5: MBR, bootstrap, bootloader : r/explainlikeimfive – Reddit
5. Understanding UEFI/GPT, BIOS/MBR, Swap, Partitions
A Gentle Introduction to the Boot Process & Dual Booting: Understanding UEFI/GPT, BIOS/MBR, Swap, Partitions, and Filesystems from linux4noobs
