Some things on how PCs boot the old fashioned BIOS way

April 19, 2017

A while back I wrote on how PCs boot and hard disk partitioning, which gave a quick description of the original BIOS MBR-based method of booting a PC (in contrast to UEFI booting). It's worth talking about BIOS booting in slightly more detail so that we can understand some constraints on it.

In practice, BIOS MBR booting goes through at least two and often three stages. The first stage loader is started by the BIOS when the BIOS loads the first 512-byte sector from an appropriate hard disk (which gets complicated these days) and then transfers control to it. Generally all that the first stage does is load more code and data from disk, in other words load the second stage. Because the first stage has only a few hundred bytes to work with, most first-stage loaders hard code the disk block locations where they find the second stage, and basically all first stage loaders use BIOS services to read data from disk.

The second stage boot code contains at least the core of the bootloader, and is often fairly comprehensive. For GRUB, I believe the second stage image contains the GRUB shell and menu system, various software RAID and filesystem modules (such as the one that understands ext4), and some other things. For GRUB, the second stage can't boot your system by itself; instead it will proceed onwards to read your grub.cfg, possibly load additional GRUB modules that your grub.cfg tells it to, and then for Linux hopefully finish by loading your selected kernel and initramfs into memory and starting them.

I believe that most second stage bootloaders continue to use BIOS services to read any additional data they need from disk (for GRUB, your grub.cfg, any additional GRUB modules, and then finally the kernel and initramfs). This means that BIOS MBR based bootloaders are subject to the whims and limitations of those BIOS services, which in some situations may be significant.

It's common for bootloaders to read data directly out of your filesystem. This obviously means that they need to be able to understand your filesystem and anything it sits on top of (such as software RAID, btrfs, LUKS, and so on). Since bootloader filesystem and so on support can lag behind kernel support, this can leave you wanting (or needing) a separate /boot that your bootloader can understand.

A certain amount of this is a lot simpler with UEFI booting. UEFI has a concept of files in a (simple) filesystem, real NVRAM variables, and a reasonably rich collection of UEFI services. This means that bootloaders don't have to hardcode disk block locations or have complicated ways of hunting for additional files; instead they can do relatively normal IO. Since UEFI will load an entire UEFI executable for you, it also eliminates the first stage bootloading.

Since UEFI booting is better in a number of ways than BIOS booting, you might imagine that an increasing number of machines are set up to boot that way. Perhaps they are for name-brand desktops that are preinstalled with Windows, but at least for Linux servers I don't believe that that's the case. Part of this is sheer pragmatics; the people putting together installers for Linux distributions and so on know that BIOS MBR booting works on basically everything while UEFI may or may not be supported and may or may not work well. Maybe in five years, server installs will default to UEFI unless you tell them to use BIOS MBR.

Written on 19 April 2017.
« For me Chrome clearly wins over Firefox on Javascript-heavy websites
The big motivation for a separate /boot partition »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Apr 19 23:19:51 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.