I am running Xubuntu 12.04 inside VMware Workstation 7. Long story short, I had created a restore script for another PC that wiped the full 512 byte MBR, ran fdisk to create some partitions, and then restored them through tools like partimage. Needless to say, I accidentally ran this script as root inside my Xubuntu VM and now it fails to boot (the script wiped the MBR and ran fdisk to create the partitions on my VM disk, but then failed and aborted, so all the data is there, it's just that the partition table is totally screwed up and now VM won't boot nor will it mount the drive when I try to run a live CD).

So how would I restore the MBR on my vmdk so that it can boot again? At the very least, how can I make it so that I can at least mount it to recover my files? It is an EXT4 drive so I'm not sure the built-in VMware tool of mapping it will work. If I created a separate VM with the same exact HD size and setup as before and ran the Xubuntu install again, could I take that MBR and restore it on my screwed up vmdk? Any help would be appreciated on this as my data is pretty important. Thanks.

Hendry, as Wyzard stated, I doubt VMware will let me attach a broken vmdk into another VM as it relies on the partition table.
–
JackJul 21 '12 at 21:50

1

@Jack, the VMDK itself isn't broken; its contents just aren't what you'd like. There should be no problem with attaching it to another VM. What won't work is VMware's feature for mounting a partition in a VMDK as a drive on the host.
–
WyzardJul 21 '12 at 22:06

Ok will give this a shot then after trying to repair the MBR with a working Xubuntu install. Thanks. Don't worry, I have a backed up version of this VM in case messing around with it screws it up even more. How exactly do I "attach" the vmdk into the new VM, vs. mounting it?
–
JackJul 21 '12 at 22:23

THIS WORKED! Thank you so much Hendry / Wyzard. I used both solutions to get this working: I attached the non-bootable vmdk to a working Linux VM, copied a "good" MBR to the disk, and then ran TestDisk to find the EXT4 superblock and repair the disk geometry. Now I can mount it in the new VM I created and copy over the files I need. Thanks again, this saved me lots of headache. First order of business now is to create a snapshot :)
–
JackJul 22 '12 at 1:20

Using VMware to mount the disk won't work because that relies on the partition table. But reinstalling to a new VM with the same size disk, and copying the MBR, might work. If you didn't customize the partitioning of the original installation, the installer should create the same partition table the second time.

However, if your script actually overwrote any partition contents (e.g. by doing a partimage restore), your data is probably hosed.

Before you do anything else, it'd be a good idea to take a snapshot of your VM in case your recovery attempts make the situation worse.

(And speaking of snapshots, double-check in case you have one from before you damaged your MBR!)

Wyzard, unfortunately, no snapshot for this VM :( I will start making daily backups in the future. The script doesn't do anything but touch the MBR (512 bytes). It wipes it and then creates a new partition layout. I will try this tonight and report back. I had already thought of this, any other ideas?
–
JackJul 21 '12 at 21:49

The partition table looks a bit better after restoring a "good" MBR, but getting EXT4 errors now: "ext4-fs bad geometry block count exceeds ...". I think resize2fs would fix the remaining problems but I am forced to run fsck.ext4, which gives me a ton of inode errors which I have to force rewrites on individually. Any ideas on how to repair the filesystem?
–
JackJul 22 '12 at 1:00

"Bad geometry, block count exceeds" sounds like your partition is too small: the size of the filesystem according to its superblock is larger than the size of the partition it's in. But since fsckfinds the superblock at least you seem to have the partition's starting address correct, which is progress.
–
WyzardJul 22 '12 at 1:09