Main boot record

Main boot record . A master boot record, also known as a master boot record (MBR ), is the first sector of a data storage device, such as a hard drive. Sometimes it is used to boot the operating system with bootstrap, other times it is used to store a partition table and sometimes it is used only to identify an individual disk device, although on some machines the latter is not used and is ignored.


[ hide ]

  • 1 Structure
  • 2 MBR and system boot
  • 3 MBR and disk identification
  • 4 Considerations in programming
    • 1 Cfdisk
    • 2 Fdisk
    • 3 FreeDOS
    • 4 TWO
    • 5 Windows
  • 5 Options on DOS / WIN95 / 98 / ME / 2000 AND XP FAT systems
  • 6 Back up the MBR
  • 7 Sources


In practice, the MBR almost always refers to the 512-byte boot sector, or the partition or sector of a partition for IBM PC compatible computers . Due to the widespread implementation of clone PC computers, this type of MBR is widely used, to the point of being incorporated into other types of computers and into new cross-platform standards for partitioning and booting.

When a data storage device has been partitioned with a partition table schema from the MBR (for example, the conventional IBM PC partitioning schema ), the MBR contains the primary entries in the partition table. Secondary partition entries are stored in extended partition logs, BSD disk labels, and Logical Disk Manager metadata partitions that are described by those primary partition entries.

By convention, there are exactly four primary partition entries in the Partition Table scheme, although in some (few) systems that number has been extended to five or eight.

When a data storage device has been partitioned with GUID Partition Table , the master boot record does not contain the partition table (although it does contain data structure models, a protection of the MBR from programs that only understand the schema of the MBR Partition Table so they don’t create partitions on the disk) and it is little used because it can affect disk partitioning.

MBR and system boot

On compatible IBM IA-32 computers using the MBR Partition Table scheme, the bootstrapping firmware found in read-only BIOS memory (currently uses flash memory) loads and executes the registry master boot. Like real-mode processors, the MBR code is made up of real-mode machine language instructions. That code normally passes control by chain loading to the volume boot record of the active (primary) partition, although some boot loaders replace that conventional code with their own.

Conventional MBR code expects the MBR partition table schema to be used, and scans the list of (primary) partition entries in the partition table looking for one that is marked with an active flag. Then load and run the Volume Boot Record for that partition (so the master boot record, like other boot sectors, is a target for viruses that infect the boot sector).

The MBR code, modified by some bootloaders, can perform a number of tasks that are different depending on the bootloader. For example, on some managers, that code loads the rest of the bootloader code from the first track of the disk (which is free space not allocated to any disk partition) and executes it. In others, it uses a disk leaderboard, which is in the same space as the code, to locate the code for the rest of the bootloader so that it can be loaded and run. Both ways have problems. The first relies on the behavior (which is not the same at all) of the disk partitioning utilities and the second requires the disk position table to be updated once changes have been made to locate the rest of the code.

On computers that do not use IA-32 processors, or on computers that use the GUID partition table schema, that schema is not correct, and the MBR is not used at system startup. Instead the firmware is able to directly understand the partitioning scheme [: en: GUID Partition Table | GPT] and the FAT file system format, so that it loads and executes programs saved as files in the System Partition. The MBR, therefore, does not intervene at all on system startup (except indirectly, as it might contain the partition table if the MBR Partition Table scheme was used).

MBR and disk identification

In addition to the boot code and the partition table, there is a third field that may be contained in an MBR: the disk signature ( Windows NT ). It has 32 bits to unambiguously identify disk hardware (not to be confused with disk drive – they don’t have to be the same on removable hard drives).

The disk signature was introduced by Windows NT 3.5 , but is currently used by various operating systems, including Linux kernel versions 2.6 and up. Windows NT uses the disk signature as an index in its registry, where it stores the relationship between partitions and disk letters. It also uses it in the boot.ini file to indicate bootable branded partitions in Windows NT.4 GNU / Linux uses the disk signature at boot to determine the position of the boot volume.

Programming considerations

It is assumed that the system being programmed uses an MBR scheme for BIOS, as indicated above, and the system BIOS locates a valid MBR on a partitioned disk during the boot sequence. As seen before, conventional MBR code loads and executes the code from the operating system volume boot record ( or bootloader ) found at the beginning of the active partition. The MBR can simply assume that the active partition on the current disk is the one to boot from, or alternatively it can be programmed as a dual-boot MBR. A dual-boot MBR must interact with the user to determine which disk partition to boot from, and must pass control to the MBR on another hard drive.

The BIOS will load the first valid MBR it finds towards the hexadecimal physical address 0x7C00, and jumps to that address. Part of the 512-byte sector is reserved for the partition table and other information (see table), so the program code must be small enough to fit just over 400 bytes of memory. The code must communicate with the user, examine the partition table, or perform management tasks such as activating line A20, or switching to unreal mode from real mode. Eventually, the MBR will need to perform its task and load the program that will do the next phase of startup, using the BIOS call INT 13.

Typically, the boot sector code also expects to be loaded from the physical address 0x7C00, even when all the memory from the physical addresses between 0x500 and 0x9ffff is available in real mode (637Kb and a half). When the MBR is already running from position 0x7C00, one of your first tasks is usually to relocate to another memory location often at 0x7A00. A volume boot record is only the size of a sector, which is not a problem since it is easy for the MBR to load much more than just a sector. Some boot loaders are larger than a sector, so loading more than one sector can speed up the boot process.


Cfdisk is a partition editor for Linux, similar to fdisk, but with a different interface (curses). It is part of the util-linux utility package.

Written in 1992, the current version is 2.12r.

If invoked without arguments, cfdisk tries to read the partition tables from disk, showing the ones found. One of the advantages of cfdisk (over fdisk) is the ability to extend extended partitions when there is free space behind them. This is not possible with either fdisk or some other partitioning programs. Below is a screenshot of a recent version of cfdisk after startup.


Fdisk is software that is available for various operating systems, which allows to logically divide a hard disk, this new space being called a partition.

The description of the partitions is saved in the partition table located in sector 0 of each disk.


The implementation of fdisk in FreeDOS has many advanced features and is free software.


IBM introduces fdisk, called ( “Fixed Disk Setup Program version 1.00”) with the launch of the IBM PC / XT, in March of 1983 , the first PC to store data on a hard disk, and the IBM Personal Computer DOS version 2.0 IBM PC DOS.

Version 1.0 could be used to create a FAT12 DOS partition, delete, change the active partition, or display partition data. The master boot record supports up to four partitions, and the other three were intended for other operating systems such as CP / M-86 and Xenix, which its own partitioning utilities like fdisk are expected to work but did not support. In August of 1984 , PC DOS 3.0 adds partitions FAT16 to support larger hard disk more efficiently.

In April of 1987 , PC DOS / fdisk 30.03 adds support for extended partitions, which could accommodate up to 23 “logical” partitions or volume units.

Support for FAT16B was added with Compaq MS-DOS 3.31, and later became available with MS-DOS / PC DOS 4.0. Most DOS fdisk programs, including the fdisk program that comes with the original Windows 95 software, are only capable of creating FAT partitions of types FAT12 , FAT16, and FAT16B .


A derivative of the MS-DOS fdisk ships with Windows 95 , Windows 98 , Windows Me, and later. Only versions of fdisk shipped with Windows 95B or earlier are capable of manipulating FAT32 partitions . Windows 2000 and later do not use fdisk, they have the role of Logical Disk Manager, as well as DiskPart. Option number 1 is used to create a primary DOS partition , for example to install.

Options on DOS / WIN95 / 98 / ME / 2000 and XP FAT systems

Option number 1 is to create a primary DOS partition, for example to install Windows 95 , 98 or ME (also for 2000 and XP but it is better to format in NTFS to install these operating systems).

Option number 2 is to establish an active partition, which serves to indicate to the bios which partition to search for the operating system first, that is, we will register the partition on which we plan to install the operating system.

Option number 3 is useful when for some reason we want to delete a DOS logical partition.

Option number 4 shows us a detailed report of all the partitions of the hard disk such as the volume label, file system, disk size (always expressed in MB).

Option number 5 only appears when we have another Hard Drive installed on the PC and this option allows us to switch between one Hard Drive or another to work on them.

Fdisk does not recognize NTFS partitions since this file system came to light with Windows NT and from there it was implemented in Windows 2000 and Windows XP operating systems .

However, although Fdisk does not work with the NTFS file system, it can show us NTFS partitions (in this case) but identifying them as Partitions or Non-DOS File Systems.

Back up the MBR

On UNIX and GNU / Linux you can use the dd command to backup and restore the MBR from a console. To make the backup:

  • dd if = / dev / xxx of = mbr.backup bs = 512 count = 1

To restore it:

  • dd if = mbr.backup of = / dev / xxx bs = 512 count = 1

Where xxx is the device, which can be hda, sda, or any other.

If you want to make a backup of the MBR, it would be advisable to copy the first 63 sectors of the disk (which would be equivalent to the first cylinder of the disk) and not just the first, since our system could have implemented the GUID system, which uses more sectors to save the information about the hard drive partitions. The instruction would be:

  • dd if = / dev / xxx of = mbr_63.backup bs = 512 count = 63

To delete it, if we do not have a backup but we need to delete the information in this sector, we have to set the 512 bytes to zero:

  • dd if = / dev / zero of = / dev / xxx bs = 512 count = 1

In Microsoft operating systems there is no direct access to the MBR. In DOS or Windows 9x, the DOS program fdisk together with fdisk / mbr (for which there is no documentation) will rewrite the MBR code. In Windows 2000 and later, the Recovery Console can be used to write the new MBR code to the hard drive. There are other utilities to edit the MBR partition table directly.

If you are making a backup of the hard disk (what is known in English as ghosting ) and give warnings that the paging file is not found, surely it can be solved with fdisk / fixmbr (executed from a floppy disk, since it is not you can enter Windows ).

In DR-DOS 6 (and possibly other versions), the FDISK program has an option to rewrite the MBR (“Re-write Master Boot Record”). When executed with this option, the old MBR is saved in OLDMBR.BIN, which can be copied to a floppy so that FDISK tries to restore the original MBR from it, in case of need for this type of backup.


Leave a Comment