3 ms·

The following is a pretty decent historical page about the pre-(U)EFI MBR (Master Boot Record) boot process: https://thestarman.pcministry.com/asm/mbr/STDMBR.h

The following is a pretty decent historical page about the pre-(U)EFI MBR (Master Boot Record) boot process: https://thestarman.pcministry.com/asm/mbr/STDMBR.htm https://thestarman.pcministry.com/asm/mbr/STDMBR.htm Note that EFI/UEFI -- occurred much later in time than MBR... The MBR boot process is also called "Legacy Boot" -- and is emulated on (U)EFI -- although it may not show as an option on some (U)EFI BIOS'es if the option is turned off... Related: https://en.wikipedia.org/wiki/Master_boot_record https://en.wikipedia.org/wiki/Master_boot_record You might also wish to check out some emulators, most notably Bochs (https://bochs.sourceforge.io/ https://bochs.sourceforge.io/) and QEMU (https://www.qemu.org/ https://www.qemu.org/) because they simulate the boot process, and if you're in their debuggers, you should be able to inspect that process step by step -- but also more generally emulators for other machines/platforms/architectures (https://en.wikipedia.org/wiki/List_of_computer_system_emulators https://en.wikipedia.org/wiki/List_of_computer_system_emulat...) because in general, most of those emulators should realistically simulate the given machine/platform/architecture's boot process... The basic theory of booting is that when a system starts, it contains a little bit of persistent memory (BIOS ROM, EPROM?) that contains a little bit of code, which is just enough code to load the data of the first block/sector of the hard disk (or other persistent storage boot device) to a specific address in memory as code -- and jump to it. This data on the first block/sector -- is a small bit of machine code -- which although fairly stupid -- knows enough about the system to load the next N blocks/sectors of the hard disk (or other storage device) -- again into memory at a specific address -- and then jump (transfer control) to it. This pattern may repeat several times, for example, GRUB's first bootsector then loads an intermediate length program (a "chainloader") from the next N contiguous blocks/sectors of the storage device, this chainloader knows more about the hardware and filesystems than the initial boot block did, and then it proceeds to do a yet longer/more complex load of the main Operating System into memory. During the final load, the main Operating System might be on discontiguous blocks/sectors and those blocks/sectors may be part of a filesystem. But that doesn't have to be the case. But whatever the case, the final load (or perhaps "bootstrap phase") is usually more complex than reading continuous blocks/sectors into memory and subsequently jumping to its start address in memory -- but not always... Another way to think about it is that a 512 byte program (the bootsector) is loaded that then loads a 32K (let's say) program (the chainloader on N contiguous blocks/sectors) which then loads the multi-megabyte (or multi-gigabyte!) OS from multiple files from multiple file systems from multiple discontinuous blocks/sectors on the physical device (let's say, for example...) Simple Program (loads) -> More Complex Program (loads) -> Most Complex Program (OS)... Anyway, there's your basic theory... Good luck!

fuzzfactor 4y ago
I also recommend the Starman for good documentation over the decades. Basically you're supposed to know BIOS/MBR booting quite well in order to make the best progress on UEFI/GPT. Originally upon powerup the BIOS would run from ROM and then boot control to a program known as the Master Boot Record which would reside on the first 440 bytes of sector 0 of the HDD. The partition table took up the final bytes of sector 0. The MBR checked which of the 4 possible primary partitions was flagged as active, and then booted control to the Volume Boot Record (Boot Sector) residing at the first sector of that particular partition which would then (usually, but specifically according to BOOT.INI on Windows [BCD today] or GRUB configs for Linux) load the OS contained within that partition. Usually by reading files from the filesystem beyond that point, but capable of being chained directly to other executable sectors. Starman can be a very good resource on underlying structures: https://thestarman.pcministry.com/asm/mbr/ https://thestarman.pcministry.com/asm/mbr/ He's got lots more pages like this, and references too. Now, straight to modern UEFI: The MBR code itself is best not there on sector 0, just an imitation partition table in the final few bytes still exists which is considered "protective" and keeps BIOS PC's from recognizing the HDD since they can not handle partitions layed out by the GPT regime. Sector 1 designates GPT drive parameters, and sector 2 begins the defining data for each partition, which by default extends to sector 33 so you have room to define many more than 4 partitions, and any of them can be booted to from a single EFI folder on a hidden ESP partition, depending mainly on the config files in the EFI folder. There are backups of these defining sectors (not the EFI folder itself) in the final area of the HDD. In the ESP partition which is often expected by MB UEFI to carry a specific ESP GUID (but often works just fine after changing to a "regular" GUID so you can unhide it for maintenance), the UEFI expects to find it formatted as FAT32, and there behold a recognizable EFI/BOOT folder containing the elusive BOOTX64.EFI file. That's the only thing normally found in the EFI/BOOT folder except for systems having bootability by the rare remaining 32-bit UEFI firmwares, then you might see BOOTIA32.EFI. Lots of times it will do just fine having an EFI folder on an NTFS partition too. UEFI 64-bit firmware just runs whatever file is currently named BOOTX64.EFI in the BOOT folder. Or falls back to secondary alternatives if not present. When you install an OS like Windows it adds an EFI/MICROSOFT folder, but each time you add a different version of Windows to a different partition, you do not add additional Microsoft folders to EFI, instead you add additional boot entries to the default boot menu already present in the Microsoft BCD file there. The OS installation procedure overwrites the existing BOOTX64.EFI file with one directing the boot process to continue from the Microsoft folder after that point, according to the NT6 boot menu you have in place at the time. Installing Linux creates an EFI/ubuntu folder for example, containing most necessary GRUB elements, while overwriting BOOTX64.EFI to direct the boot process to the ubuntu folder and use the GRUB bootmenu accessible from there. Each distinct distro will add its own folder like EFI/debian/, EFI/fedora, with the most recently added claiming the most coveted BOOTX64.EFI prize. Ideally, you install all the Windows versions you want into their designated NTFS volumes, which naturally builds up your NT6 bootmenu as you go. You will best do some BCDEDITing as you go just to keep the Descriptions in the bootmenu straight as to which entry goes to which Windows version on which partition. Ideally again, your final Linux install will be a distro that automatically detects all other Linux installations residing on their EXT-formatted partitions, while also correctly detecting & adding a bootentry for Windows, so GRUB can take you to your already-established NT6 bootmenu when you want. In the EFI/Microsoft folder you will find an os-specific file in EFI/Microsoft/BOOT named BOOTMGFW.EFI. Not to be confused with the basic EFI/BOOT/BOOTX64.EFI. These are EFI executables, either one will boot the PC from UEFI directly if you drop down to the UEFI Shell preboot using your MainBoard tools. Navigate to fsx:EFI/Microsoft/BOOT and run bootmgfw.efi to boot Windows (even without an EFI/BOOT folder present), or navigate to the main EFI/BOOT folder and run the latest BOOTX64.EFI that your final OS install has overwritten for you accordingly. Where "fsx:" is the filesystem which contains the EFI folder as detected by the UEFI firmware, often fs0. You can even find grubx64.efi files for Linux. Not only OS installs, but things like GRUB updates and BCDBOOT commands can overwrite BOOTX64.EFI. Finally, once different OS's are properly installed in a traditional self-contained way on each of their own partitions, you should be able to craft any number of alternative EFI folders or contents such that any or all of the OS choices are presented to you on a bootmenu upon powerup, booting to your established choice of default (or fallback) in case of unattended powerup. GRUB can still boot Windows but Windows NT6 bootloader can no longer boot Linux when using GPT. But you can even still make a boot floppy you can use to load OS's present on the HDD without having any boot files on the HDD at all. UEFI can also sometimes do well when it finds a good recognizable EFI folder on an MBR-layout HDD.

fuzzfactor 4y ago

I also recommend the Starman for good documentation over the decades. Basically you're supposed to know BIOS/MBR booting quite well in order to make the best progress on UEFI/GPT. Originally upon powerup the BIOS would run from ROM and then boot control to a program known as the Master Boot Record which would reside on the first 440 bytes of sector 0 of the HDD. The partition table took up the final bytes of sector 0. The MBR checked which of the 4 possible primary partitions was flagged as active, and then booted control to the Volume Boot Record (Boot Sector) residing at the first sector of that particular partition which would then (usually, but specifically according to BOOT.INI on Windows [BCD today] or GRUB configs for Linux) load the OS contained within that partition. Usually by reading files from the filesystem beyond that point, but capable of being chained directly to other executable sectors. Starman can be a very good resource on underlying structures: https://thestarman.pcministry.com/asm/mbr/ https://thestarman.pcministry.com/asm/mbr/ He's got lots more pages like this, and references too. Now, straight to modern UEFI: The MBR code itself is best not there on sector 0, just an imitation partition table in the final few bytes still exists which is considered "protective" and keeps BIOS PC's from recognizing the HDD since they can not handle partitions layed out by the GPT regime. Sector 1 designates GPT drive parameters, and sector 2 begins the defining data for each partition, which by default extends to sector 33 so you have room to define many more than 4 partitions, and any of them can be booted to from a single EFI folder on a hidden ESP partition, depending mainly on the config files in the EFI folder. There are backups of these defining sectors (not the EFI folder itself) in the final area of the HDD. In the ESP partition which is often expected by MB UEFI to carry a specific ESP GUID (but often works just fine after changing to a "regular" GUID so you can unhide it for maintenance), the UEFI expects to find it formatted as FAT32, and there behold a recognizable EFI/BOOT folder containing the elusive BOOTX64.EFI file. That's the only thing normally found in the EFI/BOOT folder except for systems having bootability by the rare remaining 32-bit UEFI firmwares, then you might see BOOTIA32.EFI. Lots of times it will do just fine having an EFI folder on an NTFS partition too. UEFI 64-bit firmware just runs whatever file is currently named BOOTX64.EFI in the BOOT folder. Or falls back to secondary alternatives if not present. When you install an OS like Windows it adds an EFI/MICROSOFT folder, but each time you add a different version of Windows to a different partition, you do not add additional Microsoft folders to EFI, instead you add additional boot entries to the default boot menu already present in the Microsoft BCD file there. The OS installation procedure overwrites the existing BOOTX64.EFI file with one directing the boot process to continue from the Microsoft folder after that point, according to the NT6 boot menu you have in place at the time. Installing Linux creates an EFI/ubuntu folder for example, containing most necessary GRUB elements, while overwriting BOOTX64.EFI to direct the boot process to the ubuntu folder and use the GRUB bootmenu accessible from there. Each distinct distro will add its own folder like EFI/debian/, EFI/fedora, with the most recently added claiming the most coveted BOOTX64.EFI prize. Ideally, you install all the Windows versions you want into their designated NTFS volumes, which naturally builds up your NT6 bootmenu as you go. You will best do some BCDEDITing as you go just to keep the Descriptions in the bootmenu straight as to which entry goes to which Windows version on which partition. Ideally again, your final Linux install will be a distro that automatically detects all other Linux installations residing on their EXT-formatted partitions, while also correctly detecting & adding a bootentry for Windows, so GRUB can take you to your already-established NT6 bootmenu when you want. In the EFI/Microsoft folder you will find an os-specific file in EFI/Microsoft/BOOT named BOOTMGFW.EFI. Not to be confused with the basic EFI/BOOT/BOOTX64.EFI. These are EFI executables, either one will boot the PC from UEFI directly if you drop down to the UEFI Shell preboot using your MainBoard tools. Navigate to fsx:EFI/Microsoft/BOOT and run bootmgfw.efi to boot Windows (even without an EFI/BOOT folder present), or navigate to the main EFI/BOOT folder and run the latest BOOTX64.EFI that your final OS install has overwritten for you accordingly. Where "fsx:" is the filesystem which contains the EFI folder as detected by the UEFI firmware, often fs0. You can even find grubx64.efi files for Linux. Not only OS installs, but things like GRUB updates and BCDBOOT commands can overwrite BOOTX64.EFI. Finally, once different OS's are properly installed in a traditional self-contained way on each of their own partitions, you should be able to craft any number of alternative EFI folders or contents such that any or all of the OS choices are presented to you on a bootmenu upon powerup, booting to your established choice of default (or fallback) in case of unattended powerup. GRUB can still boot Windows but Windows NT6 bootloader can no longer boot Linux when using GPT. But you can even still make a boot floppy you can use to load OS's present on the HDD without having any boot files on the HDD at all. UEFI can also sometimes do well when it finds a good recognizable EFI folder on an MBR-layout HDD.