Find the path to the Master Boot Record of hard drive on Fedora 15

[lafluer13]

Hello;

I would like to know: what is the path to the Master Boot Record of my hard drive on Fedora 15?

[leigh123linux]

MBR doesn't have a path, MBR is the first 512bytes on the harddrive.


If you want to back it up try

dd if=/dev/sda of=/home/*/boot.mbr bs=512 count=1

[lafluer13]

Thanks! The clarification and the method to back up the MBR on the hard drive were essential to my understanding of Linux.

[srs5694]

Be aware that the MBR holds two things:

• The first stage of the computer's boot loader (normally GRUB's first stage, on a Fedora system).
• The primary MBR partition table, which defines partitions /dev/sda1 through /dev/sda4 (or equivalent for /dev/sdb or other disks).

Backing up the MBR with dd, as leigh123linux suggests, backs up both these pieces of data; but if you want a backup of the partition table, this will not back up your logical partitions. (You might luck out on restoration if the extended partition data still exists on the disk, though.) Also, if you want to restore just one thing or the other, you've got to be careful to specify the correct part of the backup file to restore (via bs, seek, and/or skip options to dd). Personally, I don't usually mess with boot loader backups; instead, I re-install the boot loader using grub-install or similar commands, either using Super GRUB Disk to boot into my regular system or using an emergency CD to boot a recovery system.

For partition table backups, the following command will back up all your partitions (primary and logical) to a text file:

sfdisk -d /dev/sda > backup.txt

You can then restore them with the following command:

sfdisk -f /dev/sda < backup.txt

If your partition table is healthy, this is a bit more reliable than a binary MBR backup, especially if you've got logical partitions (numbered above 5 by Linux). The MBR backup can be better if there's something weird or damaged in your MBR and you want to back it up before attempting to fix it.

Also, all of this assumes you've got a BIOS-based computer and an MBR partition table. If your computer uses EFI firmware and boots in EFI mode, the MBR doesn't hold any boot loader code; that goes in the EFI System Partition (ESP). If the disk uses the new GUID Partition Table (GPT) partitioning system, the MBR's partition table holds nothing but a dummy placeholder partition; the real partitions are defined in the GPT data structures, which are located elsewhere on the disk. To back up GPT partitions, I recommend my GPT fdisk family (gdisk, cgdisk, or sgdisk), which includes a backup option that creates a binary backup file. Alternatively, you can use dd to back up the first 34 sectors of the disk -- change "count=1" to "count=34" in leigh123linux's command. To restore such a backup, though, you'll need to either use gdisk or do the math to figure out where to put everything and issue three separate dd commands, each with different seek and skip options.

[VernDog]

Originally Posted by lafluer13

Thanks! The clarification and the method to back up the MBR on the hard drive were essential to my understanding of Linux.

I use leigh123linux's metod of MBR backup on my primary/logical partitions without any problems on retore. Just make sure you don't alter or move partitons in between restore.

Also, try downloading a small script , Boot Info Script, it will give you lots of valuable information regarding your boot partitions.

[srs5694]

Originally Posted by VernDog

I use leigh123linux's metod of MBR backup on my primary/logical partitions without any problems on retore. Just make sure you don't alter or move partitons in between restore.

Be aware that backing up the MBR [i]does not back up logical partition data![/url] To understand why, you need to know that the MBR (that is, the first sector on the hard disk) holds information on the four primary partitions, but not the logical partition data. On a disk with logical partitions, one of those four primary partitions is an extended partition, which serves as a placeholder for logical partitions. The logical partitions themselves are defined in data structures known as Extended Boot Records (EBRs), which reside scattered about the extended partition. The first EBR is in the first sector of the extended partition, and each EBR contains a partition definition and a pointer to a following EBR (or a null pointer, for the last EBR).

Thus, when you back up an MBR, you back up the location and size of the extended partition. If you then accidentally wipe the MBR, you'll lose your primary and logical partitions. If you restore the MBR, you'll get back your primary partitions, and your logical partitions will also reappear if their EBRs have not been damaged. That's a big if, though. A malfunctioning disk utility might easily trash an EBR, in which case you could lose its partition and all the partitions that follow it. Restoring the MBR in a case like that will do absolutely no good.

This is the reason I recommended using sfdisk; unlike a dd backup of the MBR, sfdisk backs up data on all the partitions -- primary, extended, and logical. Restoring this data will work even if an EBR has been damaged. OTOH, an sfdisk backup omits information such as the cylinder/head/sector (CHS) representations of partitions' start and stop points. Such data is seldom useful, but if you happen to need it, a binary MBR backup will preserve it, at least for the primary partitions. Also, an sfdisk backup is reliable only if the partition table is valid when you run sfdisk. If your disk is already damaged, the sfdisk output may be unreliable, so using a binary MBR backup may be the best way to preserve its data before you attempt repairs.