On Fri, Aug 14, 2009 at 5:00 AM, Chan Chung Hang Christopher<christopher.chan at bradbury.edu.hk> wrote: > >> >> First of all, I would dd a copy of the whole drive off to another drive, so you can have a few goes at this. >> >> How do you know only those bits where lost? >> > > The dd command zeros the first 64 sectors, that is, the mbr and then the > next 63 sectors which would the bootsector of the first partition and > the next 62 sectors following that. The first partition on both disks > belong to the md device that is the basis for the physical volume for > the system. And if it had not, it would have belonged to the md device > for the /boot partition which is not a great loss. Default Redhat layout > this. > > The box is still live and I am glad he was not clueless enough to say > yes to the mkefs2 command he was following from whatever howto he had > been looking at. It looks like the lvm survived having the first 62 > sectors being zeroed. Apparently lvm uses the first 255 sectors/blocks > for lvm config data. No alarms/warnings in the logs. Certainly no panics > otherwise I would not even be able to get in. > > I get to learn something new at his expense, (which is now just a scare) > nice successor eh? :-D > > Absolutely zero data loss. What can I say? Well if he dd'd 64 sectors instead of 63 then the first sector of the first partition is going to be zero'd too. Backup the data while the stale partition table is still in memory! A reboot will make it inaccessible. Try a: # sfdisk -d /dev/sdX >/root/sdX.save Look at it and see if it contains a valid partition table, if it does then do a: # sfdisk --no-reread /dev/sdX </root/sdX.save Question now is, was the first sector of partition 1 damaged (was it 63 or 64 sectors dd'd)? If so it will require a more tricky procedure to fix. -Ross