Extended boot record
An Extended Boot Record (EBR), also known as an Extended Partition Boot Record (EPBR), is a data structure in the Master Boot Record (MBR) partitioning scheme that serves as a descriptor for logical partitions contained within an extended partition on a hard disk drive.[1] It enables the creation of more than four partitions on a disk by linking multiple logical drives in a chain-like manner, overcoming the limitation of the MBR's primary partition table, which supports only up to four primary partitions.[2] The first EBR is located at the beginning of the extended partition, with subsequent EBRs pointing to the next logical partition until the chain ends.[1] Structurally, an EBR resembles the MBR but is simpler, consisting of 512 bytes per sector: the first 446 bytes are typically unused (zero-filled) or occasionally contain boot code from loaders like GRUB or LILO; the next 64 bytes form a minimal partition table describing the current logical partition (16 bytes) and, if applicable, linking to the next one (another 16 bytes); and the final 2 bytes hold the boot signature0xAA55 to validate the record.[3] This daisy-chained format allows logical partitions to be independently addressed within the extended partition container, which is itself defined as one of the four primary entries in the MBR.[3] EBRs are essential for systems using BIOS-based booting on MBR disks, particularly in older DOS and Windows environments, and their integrity is crucial for data accessibility, often requiring specialized recovery tools if corrupted.[3]
In modern contexts, EBRs are part of legacy MBR partitioning, which has been largely superseded by GUID Partition Table (GPT) schemes that support unlimited partitions without such chaining mechanisms.[2] However, extended partitions and EBRs remain relevant for compatibility with older hardware and software, as well as in scenarios involving more than four partitions on BIOS/MBR-based devices during Windows deployment.[4]
Overview and Purpose
Definition and Role
An extended boot record (EBR), also known as an extended partition boot record (EPBR), is a data structure consisting of a single sector on a storage device that describes a logical partition within the DOS/Windows master boot record (MBR) partitioning scheme.[5] This structure enables the management of additional partitions beyond the four primary ones allowed by the MBR, by serving as a descriptor specifically for logical drives contained within an extended partition.[5] The primary role of an EBR is to act as a link in a chain of such records, which allows for the creation of multiple logical partitions inside a single extended partition defined in the MBR.[5] Each EBR embeds a simplified partition table with entries that point to the current logical partition and the location of the next EBR in the sequence, forming a singly-linked list that continues until the final entry, thereby overcoming the MBR's limitation without requiring a complete overhaul of the partitioning system.[5] The master boot record (MBR) serves as the top-level partition table that initially points to the first EBR to initiate this chain.[4] Key characteristics of an EBR include its fixed size of one sector, typically 512 bytes, and its placement at the beginning of each logical partition or segment of the extended partition.[5] Unlike volume boot records, which include executable boot code for loading file systems and operating systems, EBRs do not contain any file system boot code and instead concentrate solely on partition table entries for descriptor purposes.[5] This design ensures that EBRs function purely as organizational elements within the MBR hierarchy, facilitating efficient disk space utilization for logical volumes.[5]Relation to MBR Partitioning
The Master Boot Record (MBR) partitioning scheme, used in legacy BIOS-based systems, is inherently limited to supporting only four primary partitions due to the fixed size of its partition table, which consists of 64 bytes accommodating exactly four 16-byte entries.[2] To address this constraint and allow for additional storage divisions beyond four, the scheme introduces the concept of an extended partition, which serves as a container for multiple logical partitions managed through a series of Extended Boot Records (EBRs).[5] EBRs overcome the MBR's partition limit by enabling the creation of a chain of logical partitions nested within a single extended partition entry in the MBR, thereby supporting up to dozens of logical drives depending on available disk space.[5] In the MBR hierarchy, the primary partition table at sector 0 includes one dedicated entry for the extended partition, typically marked as the fourth or last entry to reserve space for primaries. This entry points to the starting location of the extended partition, where the first EBR resides at its beginning (often the first sector of the extended partition).[5] Each EBR mirrors the structure of the MBR but uses only two partition table entries: the first describes the immediately following logical partition, while the second links to the location of the next EBR, forming a singly-linked chain that continues until the final EBR, which describes only a logical partition without a further link.[5] This chained arrangement ensures that all logical partitions are contiguous within the extended partition boundaries, maintaining compatibility with the overall MBR layout while expanding capacity.[2] EBRs are identified and distinguished from standard partitions through specific type codes in the MBR and subsequent EBR tables: 0x05 for extended partitions using traditional CHS (Cylinder-Head-Sector) addressing, and 0x0F for extended partitions employing LBA (Logical Block Addressing) for larger disks.[5] These codes signal to the boot loader and partition tools that the entry represents an extended container rather than a bootable primary or logical segment, with logical partitions themselves using type codes like 0x06 or 0x0B depending on the file system.[5] Only one extended partition is permitted per MBR to preserve simplicity, ensuring the hierarchy remains linear and non-overlapping.[5] This integration of EBRs with MBR partitioning has been essential for compatibility across legacy operating systems, including MS-DOS, which introduced the extended partition concept to support more drives on early PCs.[5] It extends to Windows 9x and NT families, as well as modern operating systems like Windows 10/11 and various Linux distributions that retain MBR support for backward compatibility, allowing seamless access to extended and logical partitions on disks up to 2 TB.[2][5] Without EBRs, systems limited to four primaries would be impractical for multi-drive configurations common in these environments.[2]History and Development
Origins in DOS
The extended boot record (EBR) was introduced by Microsoft in MS-DOS version 3.3, released in April 1987, as an extension to the master boot record (MBR) partitioning scheme originally developed for the IBM PC.[6][7] This innovation addressed the inherent limitation of the MBR, which supported only four primary partition entries, by designating one as an extended partition that could serve as a container for additional logical partitions.[7] The primary purpose of the EBR was to enable the creation of more than four partitions on hard drives exceeding 32 MB in capacity, which was the maximum size for a single FAT16 partition at the time.[6][7] By linking multiple EBRs in a chain within the extended partition, users could organize larger storage devices into multiple logical drives, each up to 32 MB, without requiring third-party utilities that had previously been necessary for such configurations on systems from OEMs like Compaq.[6] MS-DOS 3.3 marked a key milestone in standardizing this approach for PC-compatible systems, with the feature quickly adopted by competitors such as DR-DOS 3.31 in 1988, which incorporated support for extended partitions to enhance compatibility and disk management capabilities.[6][8] However, early implementations of the EBR scheme relied on cylinder-head-sector (CHS) addressing inherited from the BIOS, imposing a 504 MB limit on accessible drive capacity due to the 10:4:6 bit constraints (1,024 cylinders, 16 heads, 63 sectors per track) before logical block addressing (LBA) extensions became available.[9]Evolution and Standardization
The introduction of Logical Block Addressing (LBA) in extended boot records marked a significant advancement to overcome the 8.4 GB limit imposed by traditional CHS addressing in BIOS INT 13h calls. With the release of Windows 95 in 1995, EBRs began supporting LBA through the new partition type 0x0F for extended partitions, enabling access to larger drives while maintaining compatibility with older systems by hiding these partitions from MS-DOS versions lacking LBA support.[10] This built on earlier efforts in MS-DOS 6.0 (1993), which improved disk access for drives up to 2 GB via BIOS extensions, but full LBA integration in partitioning awaited Windows 95's fdisk enhancements.[11] EBR structures were soon adopted across platforms beyond Microsoft ecosystems. In Unix-like systems, tools like Linux's fdisk utility incorporated support for extended partitions and EBRs from early kernel versions, allowing seamless management of MBR-based layouts on Linux distributions. Similarly, Apple's transition to Intel-based Macs in the mid-2000s utilized hybrid MBR setups with EBRs in Boot Camp to enable dual-booting Windows alongside Mac OS X, preserving compatibility for legacy partitioning on GPT-dominant systems. Standardization of EBRs was formalized through joint Microsoft and IBM documentation in the early 1990s, which defined the chain-loading mechanism and influenced the broader INT 13h BIOS extensions for handling disks larger than 8 GB.[11] These extensions, detailed in the IBM/Microsoft INT 13h specification, ensured consistent EBR interpretation across BIOS implementations, paving the way for reliable cross-OS disk access without proprietary variations.[11] By the 2000s, the EBR scheme was increasingly overshadowed by the GUID Partition Table (GPT) introduced in the UEFI specification, which offered superior scalability for modern storage.[12] Nonetheless, EBRs persist for backward compatibility in UEFI systems operating in legacy BIOS mode via the Compatibility Support Module (CSM), supporting hybrid boot environments on contemporary hardware.[12]Technical Structure
Overall Layout
The extended boot record (EBR) occupies a fixed sector size of 512 bytes and is located at logical sector 0 of the extended partition and each subsequent logical partition.[3] This positioning ensures that the EBR serves as the initial descriptor for the partition chain within the extended partition scheme.[3] The sector is divided into three primary components: a boot code area spanning bytes 0 to 445 (446 bytes total), a partition table from bytes 446 to 509 (64 bytes), and a boot signature occupying bytes 510 to 511 (2 bytes, with the value 0xAA55 in little-endian byte order, or 0x55 0xAA).[3] The partition table accommodates a maximum of two 16-byte entries: the first describes the current logical partition, while the second, if present, points to the next EBR to link subsequent logical partitions.[3] The remaining 32 bytes of the partition table (bytes 478 to 509) are typically unused and zero-filled.[3] In contrast to the master boot record (MBR), which includes executable boot code to initiate the operating system loading process, EBRs generally contain minimal or no functional boot code, with the boot area often zero-filled to prioritize data structures for partition linking.[3] However, the first EBR in the chain may include chainloading code to facilitate booting from the extended partition.[3] EBR partition table entries support both cylinder-head-sector (CHS) addressing and logical block addressing (LBA) modes, determined by the partition type and the system's BIOS or bootloader capabilities, allowing compatibility with legacy and modern disk geometries.[13]Partition Table Entries
The partition table within an Extended Boot Record (EBR) occupies bytes 446 to 509 (offsets 0x1BE to 0x1FD) of the 512-byte sector and consists of exactly two 16-byte entries, mirroring the format used in the Master Boot Record (MBR) but tailored for chaining logical partitions.[3] Each entry follows a fixed structure that encodes the partition's attributes, location, and type using a combination of legacy Cylinder-Head-Sector (CHS) addressing and modern Logical Block Addressing (LBA).[3] The structure of each 16-byte partition table entry is as follows:| Offset (bytes) | Size (bytes) | Field Name | Description |
|---|---|---|---|
| 0 | 1 | Boot Indicator | Always 0x00 (inactive) in EBRs, as logical partitions are not marked bootable. CHS and LBA fields are relative to the start of the extended partition.[13] |
| 1-3 | 3 | Starting CHS | Starting address in CHS format: head (byte 1), sector/cylinder high bits (byte 2), cylinder low bits (byte 3). Limited to 1023 cylinders, 255 heads, 63 sectors.[3] |
| 4 | 1 | Partition Type | Identifies the partition type (e.g., 0x05 or 0x0F for extended).[14] |
| 5-7 | 3 | Ending CHS | Ending address in CHS format, structured similarly to starting CHS.[3] |
| 8-11 | 4 | Starting LBA | 32-bit little-endian sector number (absolute from disk start for MBR, relative to extended partition for EBR). Supports up to 2 TiB.[3] |
| 12-15 | 4 | Partition Size | 32-bit little-endian number of sectors in the partition.[3] |
Boot Code and Signature
The boot code area within an Extended Boot Record (EBR) spans bytes 0 to 445 of the sector and serves as a space for executable bootstrap instructions, mirroring the structure of the Master Boot Record (MBR).[3] This region is typically left empty or filled with zeros in standard EBR implementations, as the EBR's primary purpose is to facilitate the description of logical partitions rather than direct booting.[3] When present, the code is minimal and designed to support chainloading, such as jumping to the next EBR sector or aiding the transition to the MBR loader.[3] In the initial EBR of a chain—located at the start of the extended partition—the boot code area may contain instructions to load the volume boot record (VBR) of the first logical partition, enabling the boot process to proceed to the file system loader.[3] This chainloading mechanism relies on the EBR's partition table entries to locate subsequent sectors, ensuring a linked list of logical partitions without embedding complex boot logic in every EBR.[16] Variations exist in non-standard setups, where boot managers or utilities might insert custom code or data into this area, though such uses are exceptions rather than the norm.[3] The EBR sector concludes with a two-byte signature at bytes 510-511, fixed as 0xAA55 in little-endian byte order (0x55 followed by 0xAA), which serves to validate the sector as a legitimate boot record structure.[3] This signature is identical to that of the MBR and is checked by boot loaders and partition tools to confirm the EBR's integrity; its absence renders the sector invalid and disrupts partition recognition.[16] Standard EBRs thus emphasize this validation over extensive boot functionality, prioritizing the partition table's role in disk organization.[3]Usage and Implementation
Chain of Logical Partitions
The chain of logical partitions in an extended partition is formed through a linked list structure using multiple extended boot records (EBRs). The first EBR, located at the beginning of the extended partition, contains two partition table entries: the first defines the starting location and attributes of the initial logical partition, which begins immediately after the EBR sector itself, while the second entry points to the logical block address (LBA) of the next EBR. Each subsequent EBR follows the same pattern, with its first entry describing the next logical partition and its second entry linking to the following EBR, creating a daisy-chain sequence until the final EBR, whose second entry is typically set to zero or an invalid LBA to indicate the end of the chain.[17][3][5] Theoretically, this chaining mechanism allows for an unlimited number of logical partitions within a single extended partition, as each EBR adds one more without a fixed table size constraint. However, practical limitations arise from disk geometry, BIOS constraints, and operating system tools; for instance, traditional IDE disks are often limited to around 63 logical partitions per extended partition due to addressing and enumeration boundaries in legacy systems, while SCSI or hotplug devices may cap at 15. These limits ensure compatibility with bootloaders and partition managers that recursively parse the chain without excessive overhead.[5][18][19] Accessing data in logical partitions involves tools that traverse the EBR chain recursively, starting from the extended partition's entry in the master boot record (MBR) and following each second-table-entry LBA to load subsequent EBRs. For example, utilities likefdisk or parted read the first EBR, extract the logical partition details, then jump to the next EBR to continue parsing until the chain terminates, thereby mapping all logical volumes for mounting or display. The actual file system data for each logical partition resides in the sectors immediately following its respective EBR, preserving space efficiency.[5][3]
If the chain is broken—such as through a corrupted EBR sector or an invalid LBA in a linking entry—subsequent partitions beyond the break become unrecognized by the system, potentially leading to data inaccessibility until recovery. Tools like TestDisk can scan for orphaned EBRs or reconstruct chains from residual data, but prevention relies on maintaining valid LBAs during partitioning operations.[3][20]