Resize operation killed, .vdi now not working anymore

[Marco Sulla]

I tried to resize my VM using VBoxManage modifyhd. I just forgot that the size should be passed as megabytes and not bytes, so I sent a SIGINT signal to the process. Now the VM does not work anymore. What can I do to repair it?

[socratis]

Restore from backup.

[Marco Sulla]

I have a backup, but I think it's a bit dated.
The problem is so serious? I'm ready to use an hexadecimal editor if it's necessary

[mpack]

The problem is so serious? I'm ready to use an hexadecimal editor if it's necessary

It depends how much damage you did. Had you let the process run to completion then at least we'd know what state the file is in, as it is your guess is as good as mine (better, since you can do diagnostics on the file).

Google for a tool called vidma "vidma site:forums.virtualbox.org". This tool is by a user, it is NOT official, and NOT supported. It is the only tool which currently can be used to shrink a vdi logical size, however like all such tools it expects the vdi to be at least self consistent, so with yours - who knows. Make a backup before you start, so at least things can't get any worse.

[Marco Sulla]

Well, it was promising:

Code: Select all

Recognized file format:
        Virtual Disk Image (vdi)

Requested disk resize
from                 40960 block(s)
to                   30720 block(s)
(each block has    1048576 bytes + 0 extra bytes)

Disk size will change
from           42949672960 bytes (          40960 MB)
to             32212254720 bytes (          30720 MB)

Image size will change
from           31884050432 bytes (          30407 MB)
to             31884050432 bytes (          30407 MB)

It do the work and when I replaced the new disk in the virtual machine, the GUI shows me no error icon. But it still doesn't boot. Furthermore I tried to mount the disk using qemu-nbd, but there's no partitions under /dev/ndb0 (nor the old image, neither the shrinked one)

[mpack]

That's what I feared. When you resize a disk in-place to a humungous size the block map needs to be enlarged. That means that early image blocks (which effectively are always your boot sector, partition map etc) get moved to the end of the VDI and the early block map links are updated to point there. Then an updated block map is written. You interrupted that process somewhere in the middle.

Also, the full extent of the catastrophe rather depends on just how big you told it to make the disk. We had an example a while back where the block map alone would have made for a file which was larger than the partition which hosted it, obviously this resulted in total loss of data - no possibility of recovery. And this guy didn't even SIGINT in the middle of the process.

If you know how to program then that is probably your only hope. Your VDI consists of a 1MB header, an nMB block map (where n = ceiling(LogicalDiskSize/256GB)), and then the disk image in 1MB blocks. Each block map entry is a UI32, giving the index of the block mapped to that portion of the linear image (index 0 is the block which immediately follows the blockmap). Block map entries can have special values too 0xFFFFFFFF=not_allocated, 0xFFFFFFFE=zero_block - both of the latter mean that no file block is allocated.

Header details can be found in the VBox source code: these details will also need to be corrected if you heavily modify the file.

[Marco Sulla]

Well, since I thought that the value to enter was in bytes, I entered 40960 Gb as new size. And to make thing worse I resized it to 40 Gb and back to 30 gb with the tool you suggested me. Should I suppose I can let the trash bin do its work?

[mpack]

And to make thing worse I resized it to 40 Gb and back to 30 gb with the tool you suggested me. Should I suppose I can let the trash bin do its work?

If you followed my instructions above then you made a backup of your damaged VDI before you did that, so going backwards isn't a problem.