Master Boot Record:

A master boot record (MBR), or partition sector, is the 512-byte boot sector that is the first sector ("LBA Sector 0") of a partitioned data storage device such as a hard disk. (The boot sector of a non-partitioned device is a Volume Boot Record. These are usually different, although it is possible to create a record that acts as both; it is called a Multi Boot Record.) The MBR may be used for one or more of the following:

Due to the broad popularity of IBM PC-compatible computers, this type of MBR is widely used, to the extent of being supported by and incorporated into other computer types including newer cross-platform standards for bootstrapping and partitioning.^{[citation needed]}

MBRs and disk partitioning

The MBR is not located in a partition, it is located at a Main Boot Record area in front of the first partition.

Where a data storage device has been partitioned with the MBR Partition Table scheme (i.e., the conventional IBM PC partitioning scheme), the master boot record contains the primary partition entries in its 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.^[12]

By convention, there are exactly four primary partition table entries in the MBR Partition Table scheme, although some DOS operating systems did extend this to five (PTS-DOS)^[13] or even eight (AST or NEC DOS)^[14]^[15] entries.

Where a data storage device has been partitioned with the GUID Partition Table scheme, the Master Boot Record will still contain a partition table, but its only purpose is to indicate the existence of the GUID Table and to prevent utility programs that only understand the MBR Partition Table scheme from creating any partitions in what they would see as free space on the disk, thereby accidentally erasing the GUID table.

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 do not use IA-32 processors, and 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. On the latter, the firmware is instead 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.

There are some MBR replacement code, that emulates EFI firmware's bootstrap, which makes non-EFI machines capable of booting from GPT partitioning scheme. (A typical example is a Multi Boot Record, which can be used as MBR and as a Volume Boot Record in the bootstrap process, hence the name. It detects GPT table and loads the EFI compatible code from disk to complete this task.)

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. Linux uses the NT disk signature at boot time to determine the location of the boot volume.^[16]

Windows NT (and later Microsoft operating systems) uses the disk signature as an index to all the partitions on any disk ever connected to the computer under that OS; these signatures are kept in Registry keys, primarily for storing the persistent mappings between disk partitions and drive letters. It may also be used in boot.ini files (though most do not), to describe the location of bootable Windows NT (or later) partitions.^[17] One key (among many) where NT disk signatures appear in a Windows 2000/XP Registry is:

If a disk's signature stored in the MBR was A8 E1 B9 D2 (in that order) and its first partition corresponded with logical drive C: under Windows, then the REG_BINARY data under the key value, \DosDevices\C:, would be:

The first four bytes are said disk signature. (Note: In other keys, these bytes may appear in reverse order from that found in the MBR sector.) These are followed by eight more bytes, forming a 64-bit Integer, in little endian notation, which are used to locate the byte offset of this partition. In this case, 00 7E corresponds to the hexadecimal value 0x7E00 (32,256_dec). Dividing this byte offset by 512 (the size of a hard disk's physical sector in bytes) results in 63, which is the physical sector number (or LBA) containing the first block of the partition (^[18]).

If this disk had another partition with the values 00 F8 93 71 02 following the disk signature (under, e.g., the key value \DosDevices\D:), it would begin at byte offset 0x27193f800 (10,495,457,280_dec), which is also the first byte of physical sector 20,498,940.

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. Part of the end of the 512 byte sector is pre-allocated for the partition table and other information (see above), so the MBR program must be tiny enough to fit within 440 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, usually by making use of 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 0x501 (address 0x500 is the last one used by the BIOS)^{[citation needed]} to somewhere short of 0x9ffff is typically available in Real mode (a total of up to 640 KB minus the first 1281 bytes of memory)^[19] 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 0x600 (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.

Differences in MBR Code

Different operating systems, disk partitioning utilities and repair tools may supply different MBR code performing the same task.

The following table shows how the MBR Code of GRUB 0.92 would appear in a hex editor ^[20]:

In contrast, the MBR code created by a Windows 2000 or XP install (seen in this next table):

Editing/replacing MBR Contents

Though it is possible to directly manipulate the bytes in the MBR sector using various Disk Editors, there are tools to write fixed sets of functioning code to the MBR . Since MS-DOS 5.0, the DOS-mode program FDISK has included the (undocumented, but widely used) switch /mbr, which will rewrite the MBR code. [Caution: Using the FDISK /MBR command from MS-DOS 6.22/Windows 95, or any earlier versions, may zero-out the partition table under some circumstances, especially if the last two bytes of the MBR sector are not "55 AA" (0xAA55)^[1]. If a DOS boot is necessary, the FDISK program from a Windows 98, or other FAT32 capable, boot disk, is a safer alternative, to ensure that only the code area, and not the partition table, is overwritten.] Under Windows 2000 or later, the Recovery Console can be used to write new MBR code to a hard disk using its fixmbr command.

Some third-party utilities may also be used for directly editing the contents of partition tables (without requiring any knowledge of hexadecimal or disk/sector editors).^[21]

In Linux, the GRUB and LILO projects have tools for writing code to the MBR sector. Namely grub-install and lilo -mbr. The grub interactive console also has commands to write to the MBR.

Hello World

Backing up/restoring the MBR

Note: If you decide to back up your MBR sector, be sure to save the file on an emergency diskette or other backup device, or just print out a text representation of its hexadecimal bytes as you would see them in a disk editor. Simply storing the file on the same disk drive it was copied from will do no good if the disk's partition table has been erased.

DR-DOS

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.

MS-DOS and Windows

For MS-DOS and Windows-based operating systems, a number of third-party utilities exist for backing-up the MBR and/or partition table data. (See the "External links" section below.)

In any case, one can use the official fixmbr command from the Windows recovery console ^[23]

Unix-like systems

The dd utility, which is available on most Unix-like systems, can be used to create backup images of the master boot record. Care should be taken when using the dd utility, as incorrect values for its parameters can cause data corruption. You must have the appropriate access to the target device in order to use these commands successfully.

To back up the MBR of a hard disk or other storage device, use the following command to create a file named mbr.bin containing the entire contents of the master boot record:

where device is the path of the device file corresponding to the entire contents of the storage device whose MBR is to be backed up. For example, the primary master IDE device (ATA bus 0, device 0) is typically represented by device file /dev/hda under Linux.

To restore the MBR from a backup file to a storage device, use the following command, which replaces the first 512 bytes with the contents of the file named mbr.bin:

To back up or restore only the executable code area, assuming that the executable code uses at most 446 bytes, use the option bs=446 instead of bs=512 when executing the appropriate command. If a full 512-byte backup has already been made, a 446-byte partial restore can still be used, but the opposite is not true (dd cannot copy more bytes from a file than it contains). Using a partial restore can be useful if both the code area and the partition table have been changed and it is necessary to restore only the original code without losing the new partition table.

Note: Before proceeding with any of the partial commands above, it is advisable to ascertain the correct number of bytes to copy from or restore to the MBR, since the size of the executable code area can vary.

Another way to repair the mbr of your USB device is install lilo then type (replacing x with the letter of your flash device) :

Changing a system from dual boot Windows & Linux to Windows only

While Linux is being installed, chances are that it installs a "boot loader" program called GRUB or LILO. These bootloaders allow the user to choose between booting Linux, Windows, or other operating systems. When reverting back to booting just Windows alone, it may be difficult to rid the computer of the menu screen.

The real problem is that the bootloader was probably installed to the executable code section of the MBR. Removing this is a little bit more difficult, but the dd utility again comes to the rescue. The executable code section of the MBR is exactly 446 bytes long. The file /dev/zero is a virtual device that continually produces zeroes (when needed), so this can be used to overwrite the executable code area.

Enter the following command at the root user command prompt to erase the executable code area:

Windows still boots if the executable code area of the MBR is erased, since the BIOS first checks the MBR for bootable code and if it does not find any, it goes on to boot the first bootable partition. Windows contains its own boot code. Wiping the MBR is enough to get rid of the Linux boot loader and go back to single-booting Windows.^[25]

References

^ ^a ^b On all IBM PC, PC compatible or any other little-endian computers, hexadecimal numbers of two or more bytes are always stored on media or in memory in reverse order (for more efficient CPU processing). Thus, the hex number 0xAA55 (or AA55h) will appear in a disk editor as the sequence: 55 AA.
^ In cases where the disk has a BIOS overlay or Boot manager installed, the partition table may be moved to some other physical location on the drive; e.g., a BIOS overlay often places a copy of the original MBR contents in the second sector ("Sector 1") then hides itself from any subsequently booted OS or application, so the MBR copy in Sector 1 is treated as if it were still residing in the first sector.
^ Peter C Norton and Scott Clark (2002). Peter Norton's New Inside the PC. Sams Publishing, 360–361. ISBN 0672322897.
^ Michael W. Graves (2004). A+ Guide To PC Hardware Maintenance and Repair. Thomson Delmar, 276. ISBN 1401852300.
^ Jean Andrews (2003). Upgrade and Repair with Jean Andrews. Thomson Course Technology, 646. ISBN 1592001122.
^ William Boswell (2003). Inside Windows Server 2003. Addison-Wesley Professional, 13. ISBN 0735711585.
^ The status fields in an unextended partition table record are used by the embedded bootstrap code within the MBR to determine which partition is bootable (it is referred to as the active partition, and there can only be one active/bootable partition within the MBR). The status fields in an extended partition table record may also be used by boot manager programs to determine which partitions are bootable.
^ Formally, values other than 0x00 and 0x80 in this field have undefined meanings and the bootstrap program may display an error message if this occurs. In practice, their meaning depends upon what the actual bootstrap code within the MBR has been written to accept. Some MBR bootstrap programs specifically look for the value 0x80 to indicate the bootable ("active") partition, others simply look for a non-zero value, and yet others look for any value with the top bit set.
^ Starting Sector fields are limited to 1024 cylinders, 255 heads, and 63 sectors. Sector counts have always begun with a 1, not a 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. "List of partition identifiers for PCs". Partition types.
^ Ending Sector fields have the same limitations as the Starting Sector fields.
^ Roderick W. Smith (2000). The Multi-Boot Configuration Handbook. Que Publishing, 260–261. ISBN 0789722836.
^ Andries Brouwer. "Properties of partition tables". Partition types. PTS-DOS uses "a special 5th partition entry in front of the other four entries in the MBR and corresponding AAP-aware MBR bootstrap code." (Brouwer).
^ Brouwer, ibid. Some OEM systems, such as AST DOS (type 14h) and NEC DOS (type 24h) had 8 instead of 4 partition entries in their MBR sectors.
^ Daniel B. Sedory. "Notes on the Differences in one OEM version of the DOS 3.30 MBR". Master Boot Records. Shows an 8-entry partition table and where its boot code differs from MS-DOS 3.30.
^ Matt Domsch. "Re: RFC 2.6.0 EDD enhancements". Linux Kernel Mailing List.
^ Microsoft. "Windows May Use Signature() Syntax in the Boot.ini File". KnowledgeBase.
^ Unlike the sector count used in the Sectors value of CHS tuples, which counts from one, the Absolute or LBA Sectors value starts counting from zero.
^ Very old machines may have less than 640 KB (A0000h or 655,360 bytes) of memory, and newer machines may allocate significant amounts of memory for BIOS uses. The INT 12 BIOS call may help in determining how much memory can safely be allocated (it simply reads the Base Memory size in KB from Segment:Offset location 0040h:0013h). In theory, only 64255 bytes is guaranteed (beginning at 0x501 and ending at 0x0ffff); in practice it is safe to assume at least 382.74 KB (ending at 0x5ffff) are available on modern hardware.
^ "The GRUB MBR".
^ For example, Power Quest's Partition Table Editor (PTEDIT32.EXE), which runs under Windows operating systems, is still available here: Symantec's FTP site.
^ Run Hello World
^ "Recovery Console". www.kellys-korner-xp.com.
^ "To install Linux and keep Windows untouched like a virgin - JustLinux Forums". www.justlinux.com.
^ "- Roleback/Recover from dual boot Windows & linux system to Windows only". http://www.tuxation.com.

Master Boot Record

Contents