Master boot record
From Wikipedia, the free encyclopedia
| Address | Size (in bytes) |
Description | |
|---|---|---|---|
| Hex | Dec | ||
| 0000 | 0 | 394 – 446 | Code Area |
| 018A | 394 | 36 | Four nine-byte primary partition table entries (optional IBM extensions to the MBR Partition Table scheme) |
| 01B8 | 440 | 4 | Optional disk signature |
| 01BE | 446 | 64 | Four 16-byte primary partition table entries (standard MBR Partition Table scheme) |
| 01FE | 510 | 2 | MBR signature (0x55 0xAA) |
A master boot record (MBR) is the first sector ("sector zero") of a data storage device such as a hard disk. It is sometimes used for bootstrapping operating systems, sometimes used for holding a disk's partition table, and sometimes used for uniquely identifying individual disk media; although on some machines it is entirely unused and ignored.
In practice, MBR almost always refers to the 512-byte boot sector, or partition sector of a disk partitioned for IBM PC-compatible computers. Due to the broad popularity of PC-compatible computers, this type of MBR is widely used, to the extent of being supported on other types of computer, and incorporated into newer cross-platform standards for bootstrapping and partitioning.
Contents |
[edit] MBRs and disk partitioning
| Offset | Description |
|---|---|
| 0x00 | Status[1] (0x80 = bootable, 0x00 = non-bootable, other = malformed[2]) |
| 0x01 | (3 bytes) Cylinder-head-sector address of the first sector in the partition[3] |
| 0x04 | Partition type |
| 0x05 | (3 bytes) Cylinder-head-sector address of the last sector in the partition[3] |
| 0x08 | (4 bytes) Logical block address of the first sector in the partition |
| 0x0C | (4 bytes) Length of the partition, in sectors |
| Offset | Description |
|---|---|
| 0x00 | Status bits[1] (bit 0 = list on Boot Manager menu, other bits = reserved) |
| 0x01 | Space-padded partition name |
Where a data storage device has been partitioned with (what Microsoft terms) the MBR Partition Table scheme (i.e. the conventional IBM PC partitioning scheme), the master boot record contains the primary entries in the partition table. The partition table entries for other, secondary partitions are stored in Extended Boot Records, BSD disklabels, and Logical Disk Manager metadata partitions that are described by those primary entries.
By convention, there are exactly four primary partition table entries in the MBR Partition Table scheme, although some (rare) systems have been known to extend this to five, or to eight, entries.[4]
Where a data storage device has been partitioned with the GUID Partition Table, the Master Boot Record does not contain the partition table (although it contains dummy data structures, a "protective MBR", to prevent utility programs that only understand the MBR Partition Table scheme from creating partitions on the disk) and is wholly unused as far as disk partitioning is concerned.
[edit] MBRs and system bootstrapping
On IA-32 IBM PC compatible machines using the MBR Partition Table scheme, the bootstrapping firmware contained within the ROM BIOS loads and executes the master boot record. Because the i386 family of processors boot up in real mode, the code in the MBR is real mode machine language instructions. This code normally passes control by chain loading the Volume Boot Record of the active (primary) partition, although some boot managers replace that conventional code with their own.
The conventional MBR code expects the MBR Partition Table scheme to have been used, and scans the list of (primary) partition entries in its embedded partition table to find the only one that is marked with the active flag. It then loads and runs the Volume Boot Record for that partition. (Thus the master boot record, like other boot sectors, is a target for boot-sector infecting computer viruses. See boot sector.)
The MBR replacement code in some boot managers can perform a variety of tasks, and what those tasks are varies from boot manager to boot manager. In some, for example, it loads the remainder of the boot manager code from the first track of the disk, which it assumes to be "free" space that is not allocated to any disk partition, and executes it. In others, it uses a table of embedded disk locations to locate the remainder of the boot manager code to load and to execute. (Both approaches have problems. The first relies on behavior that is not universal across all disk partitioning utilities. The second requires that the embedded list of disk locations be updated when changes are made that would relocate the remainder of the code.)
On machines that use Extensible Firmware Interface (EFI) firmware, this design is unsuitable, and the MBR is not used as part of the system bootstrap. Instead the firmware is capable of directly understanding the GPT partitioning scheme and the FAT filesystem format, and loads and runs programs held as files in the EFI System Partition. The MBR will only be involved insofar as it might contain the partition table if the MBR Partition Table scheme has been used.
[edit] MBRs and disk identity
In addition to the bootstrap code and a partition table, master boot records may contain a Windows NT disk signature. This is a 32-bit value that is intended to uniquely identify the disk medium (as opposed to the disk unit — the two not necessarily being the same for removable hard disks).
The disk signature was introduced by Windows NT version 3.5, but is now used by several operating systems, including the Linux kernel version 2.6 and later. Windows NT uses the disk signature as an index into its registry, where it stores the persistent mappings between disk partitions and drive letters. It may also be used in boot.ini files (most do not), to describe the location of bootable Windows NT partitions.[5] Linux uses the disk signature at boot time to determine the location of the boot volume.[6]
[edit] Programming Considerations
Assume that the system being programmed uses the BIOS MBR scheme, as stated above, and the system BIOS locates a valid MBR on a partitioned drive in its boot sequence. As stated above, conventional MBR code loads and runs the operating system dependent Volume Boot Record (or bootloader) code that is located at the beginning of the disk's "active" partition. The MBR can simply assume that the one active partition on the current drive is supposed to boot, or alternately, it can be programmed as a Dual boot MBR. A dual boot MBR must interact with the user to determine which partition on which drive should boot, and may transfer control to the MBR of a different drive.
The BIOS will load the first valid MBR that it finds into hexadecimal physical address 0x7C00, and jump to that address. Some of the end of the 512 byte sector is preallocated for the partition table and other information (see above), so the MBR program must be tiny enough to fit in a little over 400 bytes of memory. The MBR program may communicate with the user, examine the partition table, or perform some housekeeping tasks such as enabling the A20 line, or changing to Unreal mode from Real mode. Eventually, the MBR will need to perform its main task, and load the program that will perform the next stage of the boot process, typically by using the INT 13 BIOS call.
Typical boot sector code also expects to be loaded at physical address 0x7C00, even though all the memory from physical address 0x500 to address 0x9ffff is available in Real mode (a total of 640 KiB minus the first 1280 bytes). Since 0x7C00 is the location where the MBR is already running, one of the first tasks of an MBR is usually to relocate itself somewhere else in memory -- most often at 0x0600 (for Microsoft code). A conventional Volume Boot Record is only one sector long; but it does no harm and is trivial to allow the MBR to load significantly more than just one sector. Some bootloaders are longer than one sector, so loading more than one sector can speed up the boot process.
[edit] Backing up the MBR
Under UNIX/Linux, the program dd can be used to backup and restore the MBR sector.
To backup, use:
dd if=/dev/xxx of=mbr.backup bs=512 count=1
where xxx is your first storage device, such as hda, sda, or some other.
To restore, simply reverse the process using:
dd if=mbr.backup of=/dev/xxx bs=512 count=1
In both commands, if stands for 'input file' and of for 'output file'. bs is set to 512 bytes/sector, and count=1 means to copy or write only 1 sector.
Microsoft-based operating systems do not offer direct access to the MBR. In DOS or Windows 9x, the DOS-mode program fdisk with the (undocumented) switch /mbr will rewrite the MBR code. In Windows 2000 or later, the recovery console can be used to write new MBR code to a hard drive. Third-party utilities may be used to edit the partition table directly.
In DR DOS 6 (and possibly other versions), the FDISK program has an additional option to "Re-write Master Boot Record". When this is done the old MBR is stored in a file, OLDMBR.BIN. This file can be copied. If it is present on a disk, FDISK will instead prompt to "Restore Original Boot Record", and the file will be re-loaded as the disk's boot record.
[edit] References
- ^ a b The status fields in the unextended partition table records are used by the embedded bootstrap code within the MBR itself to determine which partitions are bootable. (In IBM nomenclature, such partitions are described as startable. In other nomenclature they are described as active.) The status fields in the extended partition table records are used by boot manager programs to determine which partitions are bootable. (In IBM nomenclature, such partitions are described as bootable.) In the conventional case, the "startable" partition contains a boot manager, which displays a list of the "bootable" partitions when it is itself bootstrapped.
- ^ In theory, values other than 0x00 and 0x80 in this field have undefined meanings. In practice, their meaning depends from what the bootstrap code within the MBR itself has been written to accept. Some MBR bootstrap programs specifically look for the value 0x80 to indicate a bootable ("startable") partition. Others simply look for a non-zero value.
- ^ a b These fields are limited to 1024 cylinders, 255 heads, and 63 sectors. Sector counts have always begun with a 1; not zero, and due to an early error in MS-DOS, the heads are generally limited to 255 instead of 256. When a CHS address is too large to fit into these fields, the tuple (1023, 254, 63) is used.
- ^ Andries Brouwer. Properties of partition tables. Partition types.
- ^ Microsoft. Windows May Use Signature() Syntax in the Boot.ini File. KnowledgeBase.
- ^ Matt Domsch. Re: RFC 2.6.0 EDD enhancements. Linux Kernel Mailing List.
[edit] Further reading
- P. Brady. Details of how GRUB fits into hardisk layout on a PC. www.pixelbeat.org.
- H. Gilbert. Partitions and Volumes. PC Lube & Tune.
- Daniel B. Sedory. MBRs (Master Boot Records). Boot Records Revealed!. (mirror site)[1]
- Hale Landis. Master Boot Record. How It Works.
- Understanding and Working with the MBR. www.cpqlinux.com.
