virtualbox.org

I understood. I didn't take it to mean you were saying I was wrong.

mpack: Do you want me to provide more information? You said you gonna tell me more details on how to fix it...

Also, I can give you a better estimate of the correct value for "nBlocksAllocated" if I knew the exact logical size (capacity) of the disk, and the current file size.

Thanks a lot!

I'm waiting for the exact capacity I asked for. "About 35GB" is not good enough. What does VBox say the capacity is? (and by "capacity" I mean exactly that - the maximum amount the disk can store == the size you chose at creation). I can't figure the block map size without this - and you can't create the template drive which was a fundamental part of the suggestion.

I'm afraid that I'm not able to tell you capacity, because of corruption it is not shown in Virtualbox anymore.

Very well, lets assume that you created a disk which was exactly 35GB. PLEASE NOTE THAT IF THIS ASSUMPTION IS WRONG THEN ANYTHING YOU DO FROM HERE ON WILL PRODUCE GARBAGE. I SUGGEST YOU MAKE A BACKUP OF THE FILE BEFORE TAMPERING WITH IT.

Ok, VDI capacity is 35GB. So image size = 35 * 1024**3 = 37580963840 bytes = 35840 blocks (each 1MB).

Recent versions of VirtualBox pad the block map to exact multiples of 4K, a single 4K page can map 1024 blocks (1GB), so the block map would need to contain ceiling(35840/1024) = 35 x 4K pages, hence occupying 140K.

So, a completely filled disk would consist of :-

Header (4K)
Block map (140k)
Image (35840MB)
In bytes this totals 37,581,111,296.

Lets see... the figure you gave for current file size is 37,581,111,296. Wow, spot on! You're very lucky - I guess this means the original assumption is probably correct, but you should still make that backup.

So to the fix: you need to create a new dynamic VDI of exactly 35GB. Use a hex editor to copy the first 4096 bytes of the new VDI to your damaged VDI. Next we want to set "nBlocksAllocated" to 35840 (0x00008C00), so patch the 4 bytes starting at offset 388 (0x184) to 00,8C,00,00. You should notice that the four bytes immediately before have the same value - this is the nBlocks field.

Note that this fix changes the UUID in the VDI header. Some guests may care about that, though the problem is always fixable.

This fix repairs the header and makes it consistent with the image. However I cannot guarantee that the block map and image was not also corrupted, though the part of the block map I can see does look ok.


Tell me, did you ever use VBoxManage to increase the capacity of this VDI? This might have been several months ago.

Mpack, thanks a lot! I´ve followed given instruction and could recover my VDI to working state... Many thanks again... Hope this will help also others with corrupted VDI header.

@mpack This might be useful as a tutorial for others to use.. assuming they read tutorials of course.

PetrHekr wrote:Mpack, thanks a lot! I´ve followed given instruction and could recover my VDI to working state.

I'm glad to hear it. However, I'd suggest that you start making backups of your VM at regular intervals, e.g. weekly and whenever you do something you wouldn't like to have to redo. You were lucky this time that the repair was quite easy: another guy has posted in a similar thread but in his case the header fragment he posted is complete garbage - no way to make sense of it, no hope of recovery.

There was a question I asked earlier which you didn't answer: had you ever enlarged the disk using VBoxManage?

loukingjr wrote:@mpack This might be useful as a tutorial for others to use..

I doubt the above is tutorial material. Each case is different, what was done above probably won't work next time. All that's really required is an understanding of the VDI format, which anyone get get by looking at the Storage sources from the VBox source tree. You could also study my CloneVDI sources, though in that case the information is secondary rather than definitive.

good point. plus users would need to be able to work in hex etc.

@mapack No, I have not enlarged VDI, it was untouched.

PetrHekr wrote:@mapack No, I have not enlarged VDI, it was untouched.

In that case the strange (because it left the preheader intact) corruption is still unexplained, which is a concern.

This worked for me. First did a backup, and then edited .vdi with an hex editor

I replaced the first corrupted bytes with :

Hmm. Unless you can say why you thought that patch was correct - and sufficient - then your post doesn't strike me as very useful. It isn't enough that the VM seems to boot - that doesn't prove that the disk is undamaged.

Looking a bit closer... happily your patch mostly just replaces the pre-header and only the first 8 bytes of the real header, most of which is mainly constant (from memory - I don't have the sources to check right now).

tbb wrote:This worked for me. First did a backup, and then edited .vdi with an hex editor

I replaced the first corrupted bytes with :

Code: Select all

00000000- 3C 3C 3C 20  4F 72 61 63  6C 65 20 56  4D 20 56 69 [<<< Oracle VM Vi]
00000001- 72 74 75 61  6C 42 6F 78  20 44 69 73  6B 20 49 6D [rtualBox Disk Im]
00000002- 61 67 65 20  3E 3E 3E 0A  00 00 00 00  00 00 00 00 [age >>>.........]
00000003- 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 [................]
00000004- 7F 10 DA BE  01 00 01 00  90 01 00 00  01 00 00 00 [................]

It helped me! Thank you! You found a reason, causing this?Maybe you use Intelligent standby list cleaner?