How to restore the master boot record (MBR) in Linux

Failure of the Master Boot Record (MBR) often results in messages such as Operating system not found or a stuck GRUB prompt, leaving the machine unable to start from disk. Recovering a known‑good MBR backup restores the bootloader so the installed system becomes accessible again.

On BIOS-based systems, the MBR occupies the first 512 bytes of a disk, containing both the initial boot code and the partition table metadata. A backup taken from that region can be written back with tools such as dd, provided the correct disk device (for example /dev/sda/) is targeted. Accessing the disk from a Linux live environment avoids interference from the unbootable installed system.

Writing to the MBR is inherently destructive and misdirected writes can erase the partition table or affect the wrong disk. The procedure assumes a traditional MBR partitioned disk booted in BIOS mode and a valid backup file that matches the same disk; systems using GPT with UEFI firmware may require reinstalling the bootloader into an EFI system partition instead of restoring an MBR sector.

1. Boot a Linux Live CD or USB into the live session mode so the system disk can be accessed without booting from it.
2. Open a terminal window in the live session.
3. Ensure the MBR backup file such as mbr.bak is available in the current directory or mounted from external media.
4. Verify the correctness of the MBR backup file before writing it to the disk.

   $ file mbr.bak
   mbr.bak: DOS/MBR boot sector
   $ strings mbr.bak | head
   GRUB
   Geom
   Hard Disk
   Read
   Error
   ##### snipped #####

   Output indicating a DOS/MBR boot sector and recognizable GRUB strings confirms that the file contains boot code rather than arbitrary data.

5. Identify the disk that contains the damaged MBR using a block-device listing.

   $ lsblk
   NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
   loop0    7:0    0  55.4M  1 loop /snap/core18/1932
   loop1    7:1    0  55.4M  1 loop /snap/core18/1944
   loop2    7:2    0 217.9M  1 loop /snap/gnome-3-34-1804/60
   loop3    7:3    0   219M  1 loop /snap/gnome-3-34-1804/66
   loop4    7:4    0    51M  1 loop /snap/snap-store/498
   loop5    7:5    0  62.1M  1 loop /snap/gtk-common-themes/1506
   loop6    7:6    0    51M  1 loop /snap/snap-store/518
   loop7    7:7    0  64.8M  1 loop /snap/gtk-common-themes/1514
   loop8    7:8    0  31.1M  1 loop /snap/snapd/10492
   loop9    7:9    0  31.1M  1 loop /snap/snapd/10707
   sda      8:0    0    20G  0 disk
   ├─sda1   8:1    0     1M  0 part
   ├─sda2   8:2    0   513M  0 part /boot/efi
   └─sda3   8:3    0  19.5G  0 part /
   sr0     11:0    1  1024M  0 rom

   Confirm the target disk by size and partition layout because systems may use names like /dev/sda/, /dev/sdb/, or /dev/nvme0n1/ depending on the hardware.

6. Restore the MBR boot code from the backup file to the start of the selected disk.

   $ sudo dd if=mbr.bak of=/dev/sda bs=446 count=1 conv=notrunc
   [sudo] password for user:
   1+0 records in
   1+0 records out
   446 bytes copied, 0.0028 s, 159 kB/s

   Writing the wrong file or targeting the wrong disk can corrupt the partition table or overwrite boot code on another drive; double-check the device path and backup source before running dd.

7. Confirm that the first 446 bytes of the disk now contain a valid bootloader signature that matches the backup.

   $ sudo head -c 446 /dev/sda | strings | head
   GRUB
   Geom
   Hard Disk
   Read
   Error
   ##### snipped #####

   Presence of the same GRUB strings as in the backup indicates that the boot code portion of the MBR has been restored correctly.

8. Reboot the computer from the system disk to verify that the operating system boots successfully without the live media.