31

First, I am assuming that drives and/or partitions have a linear address from start to finish. This must be the case, or else programs like dd would not be able to function as a copying mechanism.

Is the boot sector pretty much always just address 0 in this array of bytes? I suppose it depends on the filesystem being used on that drive?

Sorry I'm really not knowledgeable about these low-level things, and I want to learn!

14

Yes, the boot sector is always in sector 0 for MBR. The hard drive is divided into sectors which traditionally are 512 bytes, but 4TB+ drives are starting to use 4096 byte sectors.

You have to read or write an entire sector.

Today LBA, Logical Block Allocation, has a standard progression of sectors from 0 to the capacity of the drive.

Ancient hard drives actually use Cylinders,heads, and sectors. Wherein each head held so many sectors and each cylinder held so many heads.

The file system doesn't start in sector 0 instead the partition table indicated the start of the partition, so file systems play no part in this.

Also GPT has started to replace MBR as MBR has a limit of approx 2.2TB and has a convoluted way of representing more than 4 primary partitions. You need logical partitions and each extended partition can contain many logical partitions.

GPT has done away with many of the complexities and updated and simplified things.

Here is more details.

https://en.wikipedia.org/wiki/GUID_Partition_Table

  • 4
    To clarify in the second-last paragraph: It is an extended partition you need in order to create Logical Partitions – Canadian Luke Feb 15 at 1:48
  • 1
    Any idea why IBM required the size of a drive to be stored in CMOS rather than having it stored in the first sector of the first track on the first head? – supercat Feb 15 at 3:45
  • @supercat Don't know, but here are educated guesses. The only thing I can think of is, it makes there systems propitiatory and the hard drive can not be easily read by a standard device. This increases the odds you come to them for service. Other than that it protected the system against the possibility that sector 0 was bad. It is also possible the way the BIOS was programmed the information was needed before the disk IO driver was loaded. – cybernard Feb 15 at 4:05
  • 2
    For a BIOS based x86 PC, the existence of a partitioning table such as MBR is irrelevant. The only thing that matters is the boot signature 0x55AA at offset 0x1FE. If that signature is present, the BIOS will load the first 512 bytes into memory and pass execution to the first of those bytes. If that signature is not present, the BIOS will move onto the next disk, or give up if there aren't any left. – 8bittree Feb 15 at 18:32
  • 1
    @Scott Sorry about that, I fixed it. apparently typing faster than my brain is processing. – cybernard Feb 22 at 14:06
46

First, we'll need to specify the partitioning scheme used. The classic one for PCs is the MBR, which shares the name with the very first block of the disk (logical block address #0) in this partitioning scheme: the Master Boot Record. So, the answer to the question title for MBR partitioning is yes.

The Master Boot Record contains a maximum of 446 bytes of boot code, the partition table for primary partitions (only 16 bytes per partition) and a boot signature (2 bytes). Of each 16-byte partition entry, only 4 bytes are actually useable for specifying the first block of a partition on modern disks, and only 4 bytes for specifying the number of blocks in a partition. As a result, the starting point of a MBR partition must be within (2^32 - 1) blocks from the beginning of the disk, and the size of a MBR partition must be (2^32 - 1) blocks or less. In practice, this limits the usefulness of MBR partitioning to disks of 2 TB or less.

Traditionally, the MBR boot code would just identify the active primary partition, load the first block of that partition (sometimes called a Partition Boot Record, or PBR) and execute it. The PBR would then contain an operating-system-specific boot program. But modern bootloaders, like GRUB for Linux, or some full-disk encryption solutions, may wish to do more complex things and so won't fit in a single block.

In an old disk, back when the Cylinder/Head/Sector geometry values actually had some actual meaning, the entire first track of the first head of the disk was reserved for the MBR block alone: the convention was to start each partition at the beginning of a track, so as track #0 had its first block occupied by the MBR, the entire track was skipped, and the first partition would start at track #1 instead. As a result, the sectors on track #0 after the MBR block were available for use by more advanced bootloaders. On a MBR-partitioned disk, the GRUB bootloader will usually embed at least some parts of itself in there.

On modern disks, where LBA addressing is the norm, a new convention was established: the first partition would normally start at logical block address #2048, or exactly 1 MiB from the beginning of the disk. This would ensure that even if the disk would internally handle the blocks in groups of some power-of-two, the start of the first partition would still be aligned with the beginning of such a block group. On RAID arrays and other larger storage systems, such data alignment can be an important part for getting full performance out of the storage. As a side effect, this new convention was likely to cause even more "wasted" space between the MBR block and the beginning of the first partition.


In 2011, when the Intel Sandy Bridge microarchitecture was released, the new UEFI firmware was introduced to the masses, to eventually replace the traditional BIOS. Along with it, came a new partitioning scheme: GUID Partition Table or GPT for short. Since the MBR had a pretty fundamental maximum size limit of 2 terabytes (assuming the standard block size of 512 bytes), a new scheme was needed.

The GPT partitioning scheme actually contains a "protective MBR": the very first block (LBA #0) of a GPT-partitioned disk contains a valid MBR block that essentially says "this disk has been fully allocated to a partition type you don't know about, don't touch" to systems that only understand MBR-style partitioning. Starting from LBA #1 is then the actual partition table data of the GPT. It allows partition sizes to grow into the zettabytes range - that should be plenty for the foreseeable future.

The GPT partitioning scheme does away with the restrictions of MBR:

  • With GPT, there is no longer a limit of only 4 primary partitions per disk.
  • The MBR-style division of primary/extended/logical partitions no longer exists: all partitions are equal in that sense.

The UEFI firmware also specifies a new bootloader scheme. The bootloader no longer has a fixed location on the disk. Instead, the firmware will have a built-in capacity to read files from a FAT32-type filesystem, and a bootloader will be just a regular file on a FAT32 partition marked with a specific partition type GUID. Such a partition is called ESP, or EFI system partition. (UEFI firmware standard was developed from EFI firmware, which existed mainly on Intel Itanium systems, and the name and structure of the bootloader partition was inherited from there.)

So, for other partitioning schemes, including GPT, you cannot assume the boot sector is the first block on the drive - in fact, you cannot assume that the concept of a boot sector even exists!

  • 7
    2011? No, UEFI came around long before Sandy Bridge. GPT was created as part of EFI in the late '90s when Intel was working on Itanium. UEFI has been around since 2005. See the history of UEFI. – Jonathon Reinhart Feb 15 at 13:18
  • 7
    Before 2011 it was much more of a specialist thing. In Sandy Bridge, Intel made it mandatory, and so all Intel systems with Sandy Bridge or newer chipset are using UEFI firmware. That made it much more common. I tried to be brief, as it was not my primary purpose to write an UEFI history lecture. Looks like I wrote a bit too briefly there. – telcoM Feb 15 at 13:52
  • 5
    For a BIOS based x86 PC, the existence of a partitioning table such as MBR is irrelevant. The only thing that matters is the boot signature 0x55AA at offset 0x1FE. If that signature is present, the BIOS will load the first 512 bytes into memory and pass execution to the first of those bytes. If that signature is not present, the BIOS will move onto the next disk, or give up if there aren't any left. – 8bittree Feb 15 at 18:30
  • 3
    For the GPT scheme on BIOS systems, you can assume that the boot sector is the first block, because the scheme specifically includes a "protective MBR" that has the exact same bootcode area. (As 8bittree noted, the BIOS doesn't care about partitioning and will happily boot GPT disks.) And vice versa, you can't really assume GPT usage on UEFI systems, because the specification also defines how to create an ESP on MBR-only disks too... – grawity Feb 15 at 21:24
  • 1
    This seems like an excellent answer but unfortunately I don't understand very much of it. – Nacht Feb 16 at 12:19
3

I suppose it depends on the filesystem being used on that drive?

No. At least on a PC-compatible computer it cannot depend on the file system used.

Why?

The BIOS is responsible for loading the boot sector from the hard disk. Because it does not know about the file system used, it will always do the same. And this means: Loading sector #0.

On non-PC-compatible systems, the boot sector may be located elsewhere.

On systems with UEFI, booting also works differently.

By the way:

When booting from CD-ROM, the BIOS searches for a special sector which may be located somewhere after sector #16 (not 100% sure). This sector will contain information about the location of the actual boot sector. The BIOS must understand this information to be able to load the boot sector from the CD-ROM.

So on CD-ROMs, the location of the boot sector is indeed not sector #0 of the CD-ROM.

  • Wikipedia's article on El Torito (the bootable CD-ROM specification) has a link to this archived PDF. "This “Boot Record” must reside at sector 11 (17 decimal) in the last session on the CD." This then describes where to find the actual "boot image", which can emulate a floppy or hard disk, or be loaded directly into memory. When emulating a hard disk, the boot sector of the hard disk has to follow normal rules. – IMSoP Feb 16 at 22:38
3

Drives are split into logical sectors (which may not be the same as physical sectors), normally of 512 bytes. Some APIs may present a drive as a linear sequence of bytes but the actual interface protocol works in terms of whole sectors.

In the traditional PC BIOS sector 0 of the drive was/is known as the master boot record and contains both the initial boot code and the partition table. Individual partitions also had sector 0 as a boot sector. Traditionally under dos/windows the code in the MBR would identify the active partition and pass off code to the boot sector of the active partition.

Linux systems running on traditional PC bioses usually do things a bit differently. Typically a grub "stage 1" is installed in the MBR. This loads "stage 1.5" from the empty space in-between the MBR and the first partition. Stage 1.5 has enough capabilities to understand filesystems and load "stage 2" from a file-system on one of the partitions. Stage 2 then goes on to present the boot menu and load the kernel.

UEFI and it's partition table type GPT handle things rather differently. Sector 0 now contains a "protective MBR" that hopefully reduces the risk of non-efi aware tools accidentally destroying the GPT partition structure. The GPT partition table itself is stored starting in sector 1. The firmware is filesystem-aware and loads the boot loader from a partition.

Non-PC systems can be different again. Arm systems in particular can be all-over the map in terms of their boot processes. IIRC the imx6 boots from a hard drive by reading boot code from sector 1, leaving sector 0 free for the partition table. The raspberry pi on the other hand expects to find a MBR style partition table with a FAT partition containing it's boot code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.