Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question

2 Answers 2

up vote 1 down vote accepted

Create another VM install your favorite OS and attach the vmdk onto the new VM, then perform partition table recovery from your new installation. Give http://www.cgsecurity.org/wiki/TestDisk a try

share|improve this answer
    
Hendry, as Wyzard stated, I doubt VMware will let me attach a broken vmdk into another VM as it relies on the partition table. –  Jack Jul 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. –  Wyzard Jul 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? –  Jack Jul 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 :) –  Jack Jul 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!)

share|improve this answer
    
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? –  Jack Jul 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? –  Jack Jul 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 fsck finds the superblock at least you seem to have the partition's starting address correct, which is progress. –  Wyzard Jul 22 '12 at 1:09

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.