[Solved] VDI Invalid Header and VDI file copy error

[rubystallion]

Hi,

My Linux Mint 17.3 virtual machine hanged for quite a while and then crashed with an error message shown on my Windows 10 host OS. Now my VM doesn't work anymore, indicating that the VDI header is invalid. My VDI file has a size of 18,806,210,560 bytes. I tried to follow the guidelines in another thread "VDI Invalid Header" by vicsana1, but copying the VDI file also gives an error when I reach 55%. With xcopy the error is "File creation error - Data error (cyclic redundancy check)." and with the Windows Explorer the error is I think that the source file cannot be read (after copying 55%). I ran chkdsk /f, but still get the same error. I am not aware of any other problems with my hard drive.

Is it likely that my hard drive is physically damaged and should I just buy a new one to be safe? Or is that an error that can just normally happen with a VM crash? And should I try to just copy the file contents before and after the unreadable section using a combination of head, tail and df to replace the unreadable section with zero bytes or is that unlikely to work?

I have also uploaded the first 2M+1024 bytes of my VDI file.

Thank you in advance.

[mpack]

Is it likely that my hard drive is physically damaged and should I just buy a new one to be safe?

I'd say that the host filesystem data is definitely damaged, and you should run a chkdsk repair on it. It's impossible to say if the damage has a physical cause: if you tell chkdsk to do a thorough surface scan then you might find out, but IME it isn't always reliable. The best monitor I find is your ear, you can generally hear the drive chugging or ticking as it retries bad sector reads. If I heard that then I wouldn't accept any result telling me that the drive was good.

That all said, from your description of the event it does sound to me like there was bad sectors on the drive waiting for you to trip over them. I would personally regard such a drive with suspicion. I would probably order a new drive, and I'd definitely increase my backup frequency!

Regarding the VDI, you will need to be able to copy the entire VDI file. If the source file has read errors then you can try using xcopy with the "/C" option to ignore the errors - I've never tried this, so forgive me if this turns out to be not what I think it is. Hopefully this will still tell you where the errors are, you can use that as a guide to how much has been lost. Obviously, beyond a certain level of loss attempts to repair the damage will be pointless.

I'll get back to you with repair instructions (if possible) for the VDI, assuming you are able to copy it.

[mpack]

Ok, I have a recovery procedure for you. Please perform the following steps very carefully, because I am not there to look over your shoulder and correct you.

Incidentally, the hex editor I use is called frHed. I will assume that any other hex editor you use has the same capability as frHed.

1. First, back up your existing VDI, if you have not already done so. It is important that nothing we do here can make matters worse.
   .
2. Next, use VirtualBox to create a new dynamic VDI which has a capacity of 20GB (20480MB). You may find it convenient to create a new VM inside which you can create this VDI, however the VM is temporary and will never actually be used, so you don't need to spend any time on the VM settings.
   .
3. Using FrHed, copy only the first 512 bytes from the new vdi to offset zero in the damaged vdi (i.e. overwrite the old damaged header). You can then close the "new VDI", this is no longer required.
   .
4. Again using FrHed, edit the four bytes at offset 388 (0x184). These four bytes should currently be "00 00 00 00". Change them to be "0D 46 00 00".
   .
5. Save changes and exit FrHed. The VDI header should now be repaired. It sounds like your disk image is also corrupted at around the 50% mark. You can only hope that the filesystem damage can be repaired inside the guest.
   .

Note that this repair involved creating a new VDI header which therefore has new disk UUIDs. This can sometimes cause problems for a grub boot, in which case you'd have to edit the grub script to change the boot drive UUID.

[rubystallion]

Sorry for the late response. I managed to repair the VM using the exact steps you mentioned. Thanks a lot, you saved me much time and hassle!

I ordered a new disk and the damaged disk does sound a lot less smooth than the new disk. Cloning the disk always failed with a read error, but in the end I removed some files and moved some files to external storage and was then mysteriously able to clone the damaged disk.

Then I copied the VM with "xcopy /c" and performed the 5-step recovery procedure given above. Because of the changed UUID I also had to remove the disk from the Virtual Media Manager and then reattach it via the settings for my VM.

[mpack]

Thanks for reporting back, and I'm glad you got it working.

Most modern Windows disk imagers are smart enough to skip drive sectors that aren't in use, so it isn't so mysterious that deleting affected files allowed the disk cloning to succeed. It's also further evidence that the old drive had damaged sectors.

[FedeW]

Hi mpack, I hope your doing well.

I can not open my vitural machine, I get VDI: invalid header (see below).

Could you tell me if your suggestion applies only for rubystallion's file or I can try it with my VDI file?

I have have also uploaded the first 2M+1024 bytes of my VDI file.

Please, could you help with tihis?

Thank you in advance.

Best regards.

** ERROR **

Could not open the medium '/Users/federicowinkel/VirtualBox VMs/W7Pro64/W7Pro64.vdi'.

VDI: invalid header in '/Users/fw/VirtualBox VMs/W7Pro64/W7Pro64.vdi' (VERR_VD_VDI_INVALID_HEADER).

VD: error VERR_VD_VDI_INVALID_HEADER opening image file '/Users/fw/VirtualBox VMs/W7Pro64/W7Pro64.vdi' (VERR_VD_VDI_INVALID_HEADER).

Código resultado: NS_ERROR_FAILURE (0x80004005)
Componente: MediumWrap
Interfaz: IMedium {ad47ad09-787b-44ab-b343-a082a3f2dfb1}

[mpack]

The procedure I gave to Rubystallion was specific to him. In any case the procedure is now obsolete since I automated it in CloneVDI about three years ago. Just run CloneVDI and if it gives you a repair option, use it.

[FedeW]

It works perfect! Thanks

[mpack]

Good, thanks for reporting back.