Failed to open a session for the virtual machine New Xubuntu.
No error info.
Result Code: E_FAIL (0x80004005)
Component: ProgressProxy
Interface: IProgress {c20238e4-3221-4d3f-8891-81ce92d9f913}
Stupidly enough, my backup is just slightly too old to be useful.
Looking at the storage section in the VM settings I see:
Could not open the medium 'C:\Users\johnny\New Xubuntu.vdi'. VDI: invalid header in 'C:\Users\johnny\New Xubuntu.vdi' (VERR_VD_VDI_INVALID_HEADER).
I thought maybe replacing the pre-headers would help so I made a fresh VDI and copied the first 72 bytes of that into the old VDI file. Didn't help. Any ideas?
Thanks! The file is attached (had to add the .txt suffix because the forum didn't allow it otherwise). Size of vdi file 33772535808 bytes. How can I tell what the size of the drive I selected at creation time was?
Did you provide the first 64KB of the unmodified VDI as I asked, i.e. the one where you had not attempted to fix the preheader?
I ask because what I see is quite curious: the preheader is perfect, but everything else is garbage.
I'm sorry, but this damage is not recoverable. It does seem to me that I'm looking at part of the block table of a VDI. But, it's hard to see how the cluster order of any file could be so randomized. Was this VDI obtained using a file undelete utility perhaps?
Yep, that's the unmodified file. I also thought it was a little strange. I can't think of anything that could have caused it, there was no sudden power failure or anything like that. But this is the second time that's happened to me over the past few months. Host is Windows 8.1, guest is Xubuntu 14.04.
Can you show me 64kb from the second 1MB block in the file? I.e. 64KB starting at byte offset 1048576.
I note that the file size you gave earlier corresponds to exactly 32208 x 1MB blocks. That is close to being maxed out (I am assuming that info you gave me earlier about the disk being 32GB is accurate, not an approximation).
Speaking of maxed out, something I neglected to ask earlier: I assume this was a dynamic VDI, i.e. not fixed size?
Oh, and what was the VirtualBox version when you had this problem?
Good news: the second 64k ought to contain your block map, and it looks like yours does, and to my eye it looks undamaged. This VDI may be repairable after all.
Steps:
Make a backup of your damaged VDI so you can't make things worse.
Use VirtualBox to create a new dynamic VDI with a 32GB logical size. This size must be exact.
Close VirtualBox.
Use your hex editor to transfer the first 1MB (1048576 bytes) from the new VDI to your damaged VDI, and save.
Still in the hex editor, we now need to patch the "Number of Allocated Blocks" field in the header. This is four bytes at offset 388 (0x184), the value should be "CE 7D 00 00".
Save changes, test VDI.
Note that the UUID fields in the old header are lost, so this is NOT a 1:1 replacement for the old VDI. It may be better to create a new VM around it (step 2 above would be a good moment to create the new VM, then you can just replace the new VDI with your repaired one).
I don't see how that error relates to a corrupted VDI (I never did, but you clearly did have corruption so I concentrated on that). You must have an additional problem.
I've looked at the VDI and it seems fine, assuming this came from offset 0 in the repaired file. This is essentially a brand new VDI, so while there may be corruption elsewhere in the disk image, it should at least start to boot.
Did you create a new VM around the repaired VDI, as I suggested in my previous post?
Another thing you can do, if you have another VM that still works, is to mount this VDI in it as a second disk. That will prove if the VDI is ok.
Actually, belay all of that, because the things you are telling me makes no sense at all. We know the repaired VDI header is fine, and that's all that VirtualBox cares about.
So go back a few steps.
Create a new, blank VDI. Now you have a disk that we know is perfect. Try to mount that as a second disk in a VM, or create a new VM around it. When you've worked out how to do that without errors, then turn your attention to the repaired VDI.
