Master boot record

A master boot record, also known as a master boot record /i>, MBR) is the first sector of a data storage device, such as a hard drive. Sometimes it is used to bootstrap the operating system, other times it is used to store a partition table, and sometimes it is used just to identify an individual disk device, although on some machines the latter is not used and is ignored. Currently, DOS hard drives have a certain number of partitions, which can be 3 primary and 1 extended, or a maximum of 4 primary, of which there is only 1 boot partition, which is in charge of "booting" the entire operating system on the hard drive. According to the theory, it is the zero sector of the data storage device.

Structure

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

When a data storage device has been partitioned with an MBR partition table scheme, the MBR contains the primary entries in the partition table. Secondary partition entries are stored in extended partition records, 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 schema, although on 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, an MBR protection against programs that only understand the scheme of the MBR Partition Table so that they do not create partitions on the disk) and is rarely used because it can affect disk partitioning.

MBR and System Boot

On IBM IA-32 compatible computers that use the MBR Partition Table scheme, bootstrapping firmware from BIOS read-only memory (they currently use flash memory) loads and runs the master boot record. Like real mode processors, the MBR code is composed of real mode machine language instructions. That code normally passes control via chain loading to the volume boot record of the active (primary) partition, although some bootloaders replace that conventional code with their own.

Conventional MBR code expects the MBR partition table scheme to be used, and scans the list of (primary) partition entries in the partition table looking for one that is marked with active flag. It then loads and runs the Volume Boot Record for that partition (so the master boot record, like other boot sectors, is a target for viruses that infect the volume sector). start).

MBR code, modified by some boot loaders, can perform a number of tasks that differ from boot loader to boot. For example, in some loaders, that code loads the rest of the bootloader code from the first track on the disk (which is free space not allocated to any disk partition) and runs it. In others, it uses a disk location table, which is in the same space as the code, to locate the code for the rest of the bootloader so it can be loaded and executed. Both ways have problems. The first one relies on the behavior (which is not the same in all) of the disk partitioning utilities and the second one requires that the disk location table be updated once the 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 scheme, that scheme is not correct, and the MBR is not used at boot of the system. Instead the firmware is able to directly understand the GPT partitioning scheme and the FAT file system format, so it loads and runs programs stored as files on the System Partition. The MBR is therefore not involved at all in booting the system (except indirectly, insofar as it could contain the partition table if the MBR Partition Table scheme has been used).

On Windows systems, the partition table is not the only vital information in the MBR. Since Windows NT 4, Microsoft maintains 4 bytes starting at position 0x1B8 to serve as the complete physical drive identifier. It is used by the system to reference it independently from the drive letter or bus connection. The identifier is kept in different places in the registry, and is a key piece during system startup. A test performed on Windows Vista makes the system unbootable after a change of those four bytes. The displayed error message blames the problem on a hardware or software change.^{[citation needed]}.GNU/Linux also makes use of that identifier since kernel version 2.6.^{[citation required]}

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 (from Windows NT). It has 32 bits to uniquely identify disk hardware (not to be confused with disk drive — they don't have to be the same on removable hard drives).

Disk signing was introduced by Windows NT 3.5, but is currently used by several operating systems, including versions 2.6 and later of the Linux kernel. Windows NT uses the disk signature as an index into its registry, where it stores the relationship between partitions and disk letters. It is also used in the boot.ini file to indicate partitions marked bootable on Windows NT. GNU/Linux uses the disk signature at boot time 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 BIOS of the system locates a valid MBR on a partitioned disk during the boot sequence. As seen before, the conventional MBR code loads and executes the code from the operating system's volume boot record (or bootloader) found at the beginning of the active partition.. The MBR can simply assume that the current disk's active partition is the one to boot from, or alternatively it can be scheduled as a dual-boot MBR. A dual-boot MBR must interact with the user to determine which disk partition to boot from and has to hand over control to the MBR of another hard disk.

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

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

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 copy (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 copy 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 only the first one, since our system could have implemented the GUID system, the which uses more sectors to store information about hard drive partitions. The instruction would be:

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

To delete it, if we don't have a backup but we need to delete the information from 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. On 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, 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 doing a backup of your hard disk (known as ghosting) and it gives warnings that the paging file is not found, you can probably fix it with fdisk /fixmbr (executed from a floppy disk, since it won't be able to get into 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 run with that option, the old MBR is saved to OLDMBR.BIN, which can be copied to a floppy so that FDISK tries to restore the original MBR from it, should such backups be necessary.