On how PCs boot and hard disk partitioning

November 30, 2011

Starting from the very early days, PCs have booted in a very simple manner: the PC BIOS found the boot disk, loaded the first 512 byte sector from it into memory, verified that it had a valid MBR signature, and then jumped to the start of the sector (which had better be code). That was it. The code in the boot sector was responsible for doing everything else, calling on BIOS services as necessary for things like reading more data from the disk.

(Generally the code in the first sector is just smart enough to load the rest of the bootloader's code from disk. It's the second stage code, or sometimes even third stage code, that is capable enough to do all sorts of traditional bootloader things like displaying menus and so on.)

This simplicity means that in theory, a PC BIOS is completely agnostic about the presence and contents of the traditional MBR partition table (which under normal circumstances is located at the end of the first sector, reducing the amount of space available for MBR boot code somewhat). The MBR partition table and extended partitions only matter to the boot code, the OS, and any tools that you use, so you could replace them with another partitioning scheme entirely if you wanted to and everything agreed on it. I believe that this was (and is) sometimes done by various Unixes.

(In practice there are undoubtedly PC BIOSes that do care about the MBR partition table and get upset if it isn't there or isn't right. Also, a non-MBR partitioning scheme will make any MBR-based tool think that your disk is unpartitioned, so most OSes with their own partitioning schemes embed them inside one or more MBR partitions.)

Since MBR partitioning is a convention, you can replace it with another one without affecting how PCs boot (especially if you leave behind a more or less fake MBR to pacify MBR-aware things). You don't even need the BIOS's cooperation, you can do it entirely on your own.

(Note that some BIOSes, especially laptop BIOSes, have features that know about hidden MBR partitions and so on that are used for stuff like special recovery modes. I believe that this is generally separate from actually caring about them for ordinary booting.)

Sidebar: Linux and partitioning

Linux is unusual as a PC Unix in that it does not have its own partitioning scheme but uses normal PC primary and extended partitions. I believe that the reason for this is essentially historical. All of the other PC Unixes descend from ancestral Unix versions that already had their own disk partitioning schemes when they were ported to PCs. The simple way to do these ports was to embed the existing partitioning scheme inside a PC partition and then add a little bit of extra code to find it, rather than rewrite the entire disk partition handling code to take information from either the PC partitions or the Unix's own disk partition scheme.

(These Unixes generally did not want to throw away their existing partitioning schemes, partly because they wanted to be portable to non-PC systems and partly because they had a lot of existing tools, documentation, and practice that worked with the current partitioning schemes. Some of the resulting workarounds are a bit awkward.)

By contrast Linux started from scratch with no existing disk partitioning scheme to carry over into the PC world. So it made perfect sense to use the existing PC partition stuff (which Linux needed to understand a bit of anyways) rather than invent an entire new layer of disk partitioning.

Written on 30 November 2011.
« My mouse button bindings in fvwm, my window manager
The many ways PCs can dual boot multiple OSes »

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

Last modified: Wed Nov 30 17:45:01 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.