I am running FC3 with Grub in the /dev/hda MBR and / in /dev/hda7 .

I accidently zeroed my mbr. I have not rebooted. I have a backup file MBR.bin that I made last year. I don't think I changed the partitions since making the backup, but am not sure. Could I dd the MBR file to /dev/hda, do an fdisk p command, and compare the results to the output of gpart to see if they agree?

Is there another way to check if the MBR.bin agrees with my current partition structure, or to determine the partition structure from /proc?

I also have a recent dar backup. Is there a way to restore the MBR from it?

What is the best way for me to go from here?

boot from the CD in rescue mode
then
#chroot /mnt/sysimage
#grub-install <device name> (like /dev/hda1)

that should fix the boot record...u dont need a backup though

I discovered the file /proc/partitions, which has the partition structure that I zeroed out in the MBR. I copied it to another file system, so I won't lose it when I reboot.

I plan to try using dd to copy my backup MBR to the first 500 bytes of /dev/hda. Then I'll execute fdisk to print the partition table. If it is the same, I think I'll be done, and won't have to reinstall grub. Right?

If not, I'll still need to find out how to change the partition table in the MBR without affecting the data on the drive. Could I do this by executing fdisk with the first 500 bytes of /dev/hda zero, creating partitions according to the partitions file, and doing the grub-install? Could I do it by passing the partition structure to gpart -W?

Erkk !!! - how do you accidently zero the MBR ???.

You seem to have a fixation with the number 500 - did you merely zero just 500 bytes, or the whole sector ???.
May not matter, but fdisk (and cfdsik) for example won't open a disk without the signature bytes. If you only blotted 500 bytes, this won't affect you. Haven't tested if the following tools suffer the same restriction.

gpart may do the job for you, and testdisk has had good reports from people I've recommended it to.
Rebuilding the part table will not (for some value of "not" ) mangle your data. Simply indicates the start and end (and sector count, and ... well, you get the idea) - not a problem.
UNLESS it's wrong - obviously that has the potential to hurt.

Once you're happy with the rebuilt part table, then you can re-install grub - that's a no-brainer. And yes, you should re-install - it also has sector offsets in it. Easy to install and be sure. Save the grub.conf/menu.lst first.

Before you do any more damage, you really should clarify how you "zeroed the MBR". It might help us suggest possible fixes.

I forgot about the last 12 bytes. The bad command was dd if=/dev/zero of=/dev/hda bs=512 count=1. I was trying to wipe out another drive in preparation for reallocating the partitions, but I pasted the command and forgot to correct the "of=" parameter.

'Rebuilding the part table will not (for some value of "not" ) mangle your data." I understand that if only the partition table is touched then the partition data is unaffected, and if the resulting partition table is correct, then the filesystems will be correctly mounted when I reboot.

I don't understand what fdisk does: does it store anything in the partitions when creating or modifying the partition table? I would guess not, since creating the filesystems is a separate operation, but I would like to be sure. Since gpart and testdisk are designed to fix the partition table, I would not expect them to touch the filesystems, but fdisk worries me.

I decided to check testdisk, and liked what I saw, so I installed and executed it. The results looked right, but were not formatted the same as the /proc/partitions file. I decided to save the partition table and execute the fdisk print command. fdisk shows hda1-hda9 the same as a previous fdisk, before I zeroed the MBR, and hda10 looks right, so I think the partition table problem is solved.

Since the testdisk suggestion worked so well, I'll also take the suggestion to do a grub-install /dev/hda1.

Added: the GRUB manual says to execute grub-install /dev/hda, so I did that instead. Then I remembered that /dev/hda1 is mounted to /boot, so I am again doubtful. Are the two grub-install commands equivalent, or should I re-install to hda1?



Thanks for the advice.

fdisk is fine, it just defines the limits of the partition(s) as you would expect.
But it just won't talk to the disk if the entire first sector is zapped - see some of my mutterings here if interested.
So obviously testdisk did it's job if you could get fdisk to fire up.

As for grub, it *has* to be installed into the MBR - you currently have no loder code in there at all.
Remember ??? - some-one zeroed it out ....

If nothing helps you can use testdisk utility from www.cgsecurity.org .
This tool searches the disk for partitions and adds them to the partition table.