virtualbox.org

Tried to start my VM, got:

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?

Dump the first 64k of the VDI to a binary file. Zip it and attach it here. I'll take a look.

Naturally I'm only interested in seeing the original file you didn't modify.

It would also be useful to have the following stats :-

1. The logical size of the drive that you selected at creation time.
2. The current exact size of the VDI file, in bytes.

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?

johnny1111 wrote:Thanks! The file is attached (had to add the .txt suffix because the forum didn't allow it otherwise).

Yes, that's one of the reasons why I asked you to zip it.

johnny1111 wrote:Size of vdi file 33772535808 bytes. How can I tell what the size of the drive I selected at creation time was?

You mentioned an old backup. Open that using CloneVDI and report the disk size.

The original disk size is 32GB.

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.

Ok, lets not give up quite yet.

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?

Sorry for the late reply, just saw this.

VirtualBox version is 4.3.26 r98988, and yeah the VM was dynamically sized. I'm attaching the byte sector you requested.

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:

1. Make a backup of your damaged VDI so you can't make things worse.
2. Use VirtualBox to create a new dynamic VDI with a 32GB logical size. This size must be exact.
3. Close VirtualBox.
4. Use your hex editor to transfer the first 1MB (1048576 bytes) from the new VDI to your damaged VDI, and save.
5. 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".
6. 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).

Hmmm, I'm guessing I did something wrong here. Here's the error I get when I start the VM after the changes:

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}

And I'm attaching the sector you suggested I change. Where did I go wrong?

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.

So I went ahead and mounted the .vdi in a second, fresh VM, and got:

Failed to open a session for the virtual machine New xubuntu rescue.

No error info.

Result Code: E_FAIL (0x80004005)
Component: ProgressProxy
Interface: IProgress {c20238e4-3221-4d3f-8891-81ce92d9f913}

As for creating a second VM around the repaired .dvi, how would I go about that?

johnny1111 wrote:So I went ahead and mounted the .vdi in a second, fresh VM, and got:

Failed to open a session for the virtual machine New xubuntu rescue.

Was the VM giving an error message before you added the second VDI?

johnny1111 wrote:As for creating a second VM around the repaired .dvi, how would I go about that?

Create a new VM, when you get to the disk creation step say "use existing" and select the repaired VDI.

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.