Partition table missing in VDI after resize?

[Martin]

(Vbox 5.0.26 on Fedora 24)

During the last hours of the free Win 10 Upgrade I wanted to try upgrading my Win 7 guest.
I created a snapshot and started the upgrade program which told my that it needed more free disk space.
- used 'VBoxManage list hddss' to get the UUID of my 50GB Win7.vdi
- called 'VBoxManage modifymedium 20bc0265-8b8e-4682-9eb1-af5cab36f122 --resize 60000' to add aditional 10GB
Here I used the UUID of the base VDI, not the one of the snapshot...

After this the guest doesn't boot anymore, error message "No bootable medium found"
Both the base vdi and the snapshot show a size of 60000 MBytes.
I tried reverting to the snapshot but no change.
Diskpart from a Win 7 ISO doesn't see any partition on the disk.
Testdisk doesn't find a partition.

After some more tries to boot the guest I now see to snapshot files in "list hdds" but only the first "Snapshot 1" shows up in the gui.

Code: Select all

$ VBoxManage list hdds
UUID:           20bc0265-8b8e-4682-9eb1-af5cab36f122
Parent UUID:    base
State:          created
Type:           normal (base)
Location:       /home/martina/VirtualBox VMs/Win7/Win7.vdi
Storage format: VDI
Capacity:       60000 MBytes
Encryption:     disabled

UUID:           8748bc66-abec-4361-87f9-b0085331752c
Parent UUID:    20bc0265-8b8e-4682-9eb1-af5cab36f122
State:          created
Type:           normal (differencing)
Location:       /home/martina/VirtualBox VMs/Win7/Snapshots/{8748bc66-abec-4361-87f9-b0085331752c}.vdi
Storage format: VDI
Capacity:       60000 MBytes
Encryption:     disabled

UUID:           b7f2f710-7911-4363-953d-829e9800bcb0
Parent UUID:    20bc0265-8b8e-4682-9eb1-af5cab36f122
State:          created
Type:           normal (differencing)
Location:       /home/martina/VirtualBox VMs/Win7/Snapshots/{b7f2f710-7911-4363-953d-829e9800bcb0}.vdi
Storage format: VDI
Capacity:       60000 MBytes
Encryption:     disabled

[mpack]

Resizing a VDI that is part of a snapshot chain is a very risky thing to do, as you will appreciate from the resizing FAQ. You are an experienced volunteer, so you certainly already know the basic answer here: if the data is important to you, then make a backup before doing anything risky to the VM. I take it that didn't happen.

Also, if something breaks, make a backup before attempting repair! That attempt to revert is worrying, as it may have made things worse. Hopefully you really meant revert and not delete. Or, hopefully you made that backup.

Nothing reported so far tells me the reason for the failure. It would be interesting to know what CloneVDI says about the base, and also about the snapshot - if that is still available.

[Martin]

I only tried to revert to the snapshot, it is still there. None of my tests should have changed the base vdi.
I should be able to do a test with CloneVDI this evening.

[Martin]

I started CloneVDI on the base VDI

[mpack]

Well, CloneVDI seems to be saying that the post-resize VDI header is fine, but the boot sector has clearly been overwritten with random junk, heaven knows how. If that's all then a repair might be possible from inside the guest - some tool similar to fixmbr.

If the blocks are not erased, but have in effect been randomly shuffled, then there would be nothing practical I can think of to do.

Hopefully you've now made that backup to ensure that things can't get any worse?

[Martin]

I now have a copy of that file to do my recovery tests on

[Yannlieb]

I face the same issue, although I didn't have any snapshot (which seems to be an issue for resizing). I resized my .vdi (using vboxmanage modify hd on a Mac OS guest) and lost the complete partition table.
I so far have tested testdisk from Gparted live cd, but it doesn't find anything in the vdi...

Were you able to find a way to recover it since your last post ?

[mpack]

I think for the devs to take any interest in this you'd have to describe a repeatable fault. It would help if you were aware of anything unusual about the partition map on the VDI, though last I heard, VirtualBox still knows nothing about guest OS structures, only disk sectors.

Had either of you flagged the VDI as representing an SSD?

If there is a bug, my best guess is that they may have quietly added code to "trim" unused blocks while resizing, and it is trimming away block zero (which usually contains the partition map, but for newer OS's it doesn't contain partitions). CloneVDI once had a similar bug.

[nlmarco]

I just encountered the same problem. I use VirtualBox 5.1.6-dfsg-2 as shipped with Kubuntu 16.10. But my VMs are pretty old (about 3 years) and thus have been created with VirtualBox 4.x or even older (don't remember the version from years ago).

Here's what I did:

1) I shut down the VM and copied the entire directory as a backup.

2) I used the following command to resize my VDI which does not have any snapshots and which is dynamic:

Code: Select all

VBoxManage modifymedium ~/.VirtualBox/VMs/Oracle\ 11g\ on\ Kubuntu\ 12.04/Oracle\ 11g\ on\ Kubuntu\ 12.04.vdi --resize 160000

3) Tried to boot the VM, but got:

Code: Select all

FATAL: Could not read from the boot medium! System halted.

4) I read that maybe the problem was caused by some VirtualBox process still running. So I shut down all VMs and the VirtualBox management GUI as well. I checked whether all processes are gone with

Code: Select all

ps aux | grep virt

and it didn't show any VirtualBox process anymore.

5) I restored my backup (from step (1)) and booted the VM again -- it worked fine.

6) I shut down the VM again, made sure all VirtualBox processes are gone (using

Code: Select all

ps aux | grep virt

to check) and repeated step (2).

7) I stated the VM again and got the same error as in step (3).

8) I shut it down, registered a Kubuntu live CD and booted from the live CD.

9) In the konsole,

Code: Select all

fdisk /dev/sda

said that there was no partition table :-(

10) Following the advice I read here and elsewhere, I cloned the VDI:

Code: Select all

VBoxManage clonemedium Oracle\ 11g\ on\ Kubuntu\ 12.04.vdi Oracle\ 11g\ on\ Kubuntu\ 12.04\ -\ root.vdi --format VDI --variant Standard

11) I started the VirtualBox GUI and in the storage section of my VM, I switched to the new VDI file.

12) I started the VM with the new VDI for testing. It worked fine. Hence I shut it down again.

13) I resized the new VDI:

Code: Select all

VBoxManage modifymedium ~/.VirtualBox/VMs/Oracle\ 11g\ on\ Kubuntu\ 12.04/Oracle\ 11g\ on\ Kubuntu\ 12.04\ -\ root.vdi --resize 160000

14) I started the VirtualBox GUI again and started the VM: YABBADABBADOOOOO -- it worked! It seems to me that the new VirtualBox has a compatibility problem with the old VDI, created by an older VirtualBox. After all, the two VDI files have been created with the same settings and I already resized the old VDI successfully (!) about a year ago with an older VirtualBox version.

15) For the sake of completeness, here's what I did afterwards to finish resizing: Inside the VM, I opened a konsole and did:

Code: Select all

sudo -i
fdisk /dev/sda
d
n
p
<multiple times enter for accepting defaults>
w
reboot

16) Now the partition takes the entire VDI, but the file system is still too small. So after the reboot, I opened a konsole again and did:

Code: Select all

sudo -i
resize2fs /dev/sda1
df -h

Everything perfect as it should be now ;-)

17) Rebooted again to make sure the system is bootable.

18) Shut down the VM, unregistered the old VDI, deleted the old VDI, started the VM again.

[socratis]

I use VirtualBox 5.1.6-dfsg-2

Please see the following two tickets. Both of them were fixed with VirtualBox 5.1.10, so yes, you are affected by this:

• #15983: VDI image resize yields unbootable VDI.
• #16099: Possible Disk Corruption with total data loss, caused by VDI resize.

Also another note, if the VirtualBox app is coming from your distro's app-store, then it's a fork. Download the official one from https://www.virtualbox.org/wiki/Downloads