3.2.8 Regression: Snapshots and virtual disks are inacessible

[Mr.Snipfold]

​http://s46.radikal.ru/i113/1008/49/05253bf89297.png

[Mr.Snipfold]

Log File of Bad Virtual Machine

[Frank Mehnert]

The reason is that an older release of VirtualBox wrote a wrong information to your .vdi images. VBox 3.2.8 is more paranoid. We will provide a tool to fix the affected .vdi images very soon.

[Klaus Espenlaub]

Only some base .vdi images are affected, the snapshots need no fixing. The fact that the base .vdi was declared inconsistent (having a non-zero parent UUID) makes the snapshots implicitly inaccessible too.

The investigation which VirtualBox versions updated the information incorrectly is still ongoing. We know that newly created images were never affected, this situation must have been created by deleting snapshots or cloning images. Current VirtualBox versions are working correctly, so we're trying to find out which old versions might have had bugs, in parallel to developing a tool which allows to repair such inconsistent images.

[Jason]

Not sure if this helps, but I found going to virtualbox-ose 3.2.0 cleared the problem for me (Synaptic would not let me force previous versions on the full virtual box)

What I did:

1. Backuped ~/.virtualbox just in case.
2. Completely uninstall VirtualBox
3. Delete all the vbox related folders under /var/lib/dkms (seems the uninstall leaves these hanging around and they cause the virtualbox-ose-dkms install to fail)
4. Install virtualbox-ose (version 3.2.0)

[Klaus Espenlaub]

Sure, going back to 3.2.6 or earlier is a workaround. We also plan to repair the incorrect images automatically in a future VirtualBox release (3.2.10 if possible), but that needs more time than a quick repair tool.

[Klaus Espenlaub]

We just uploaded a tool which can be used to repair the affected disk images. The URL for downloading them is ​http://www.virtualbox.org/download/VBoxFixHdd/

Make sure you get the right file for your OS type. MD5 checksums are available, for checking that you got the correct file contents.

The use of the VBoxFixHdd tool is quite easy, however keep in mind that it does its changes without asking any questions. If you use it on diff images it will cause problems. If you want to be able to revert the change make sure you keep the output of the tool, together with the filename which you used it with.

Enough words of warning, let's fix your images:

1. Identify the affected images. You can either use the VirtualBox GUI and check which base images are inaccessible, but shouldn't be. The same can be done with "VBoxManage list hdds", in this case make sure you only look at images which say "Parent UUID: base".

2. Run the repair tool:

   VBoxFixHdd --filename /path/to/image.vdi --zeroparentuuid
   

   Repeat for all affected images.

That's it. The tool can fix images in all formats supported by VirtualBox.

After you're done, double check the results either in the VirtualBox GUI (go to the Virtual Media Manager and click on the "Refresh" button), or with

VBoxManage list hdds

The images should show up as accessible now.

[davescafe]

After upgrading to 3.2.8, I received an error very similar to the one displayed in the screenshot attached to the original description in this ticket. Specifically, it said the .vmdk associated with my virtual machine "is differencing but it is not associated with any parent medium in the media registry".

The fix posted in this ticket apparently will not help me. I have searched my .VirtualBox folder, and I cannot find any .vdi files. So I have nothing to point the fix script to. in the mean time, I un-installed 3.2.8 and installed 3.2.6 and things seem to be working fine.

Details on my setup: Host: Ubuntu 10.4 Guest: Windows XP SP3 Snapshots: One

[Klaus Espenlaub]

Replying to davescafe:

The fix posted in this ticket apparently will not help me. I have searched my .VirtualBox folder, and I cannot find any .vdi files. So I have nothing to point the fix script to. in the mean time, I un-installed 3.2.8 and installed 3.2.6 and things seem to be working fine.

I have no idea what makes you believe the VBoxFixHdd tool wouldn't work - to quote it from above "The tool can fix images in all formats supported by VirtualBox.". The .vdi there was just an example.

[Klaus Espenlaub]

In the mean time, a user has brought another variant of the same problem to my attention: If you export a VM having snapshots as OVF with VirtualBox 3.0 or 3.1, you get a .vmdk file included which has an incorrect parent uuid field, so it cannot be imported with VirtualBox 3.2.8. The VBoxFixHdd utility can be used in this case too, with the .vmdk file which comes with the .ovf file. After fixing you must delete the accompanying .mf file (if present), as the repair will otherwise cause the checksum verification to fail.

[Andy]

I am trying to download the OS X version of VBoxFixHdd from the link above but it just opens as a text file and a direct download saves it with the .txt extension. Can you please advise what I am doing wrong. How do I download the tool for OS X? Thanks, Andy.

[Frank Mehnert]

Please rename the .txt file to VBoxFixHdd without extension and make it executable (chmod +x VBoxFixHdd). Then start this application directly from the command line.

[Andy]

Perfect, thank you. Renamed file and set to executable, then ran against my 4 'broken' disk images. I'm now fully working on 3.2.8 Thanks again, Andy.

[Lucio01]

Hello, With VB 3.2.8, i'm having similar problem, i cannot launch my VBoxes (an ubuntu and a Windows XP are failing the same way) I've tried to patch the vdi, no change.

Lucio

[Frank Mehnert]

Replying to Lucio01:

With VB 3.2.8, i'm having similar problem, i cannot launch my VBoxes (an ubuntu and a Windows XP are failing the same way) I've tried to patch the vdi, no change.

This problem is completely different. Did you properly install VirtualBox or were there any problem during the installation? Did this VM work with VBox 3.2.6 but does not work anymore with VBox 3.2.8? Did you change any VM setting?

[Craig]

I have downloaded the Linux version of VBoxFixHdd into .VirtualBox/HardDisks and run it from there in Terminal using sudo ./VBoxFixHdd-Linux --filename {d32ace5f-2d4d-4407-8b51-2b67a0a1949a}.vmdk --zeroparentuuid. All I get back is "command not found".

I'm running Ubuntu 10.4(x64) and the full (i.e. not OSE) VB 3.2.8 latest update. Any advice?

[Craig]

Further to my last, I found I'd not made the downloaded file executable. I now have by using: $ chmod +x ./VBoxFixHdd-Linux. The VM is now working:)

[Lucio01]

Replying to frank:

Replying to Lucio01:

With VB 3.2.8, i'm having similar problem, i cannot launch my VBoxes (an ubuntu and a Windows XP are failing the same way) I've tried to patch the vdi, no change.

This problem is completely different. Did you properly install VirtualBox or were there any problem during the installation? Did this VM work with VBox 3.2.6 but does not work anymore with VBox 3.2.8? Did you change any VM setting?

Hi, It was working nicely with previous version. I've upgraded my Ubuntu with synaptic, i did not notice errors/warnings. And now it is not working anymore. I've not change settings (i've tried to simplify: remove network, remove virtual CPUS, etc on unused VMs) but the result is still the same. Lucio

[Lucio01]

Replying to Lucio01:

Replying to frank:

Replying to Lucio01:

With VB 3.2.8, i'm having similar problem, i cannot launch my VBoxes (an ubuntu and a Windows XP are failing the same way) I've tried to patch the vdi, no change.

This problem is completely different. Did you properly install VirtualBox or were there any problem during the installation? Did this VM work with VBox 3.2.6 but does not work anymore with VBox 3.2.8? Did you change any VM setting?

Hi, It was working nicely with previous version. I've upgraded my Ubuntu with synaptic, i did not notice errors/warnings. And now it is not working anymore. I've not change settings (i've tried to simplify: remove network, remove virtual CPUS, etc on unused VMs) but the result is still the same.

I've fallen back to VB 3.2.6, it works. So even if the problem is not the one described in this ticket, i've another pb with the version 3.2.8. Lucio

Lucio

[bobfitz]

Replying to craig100:

Further to my last, I found I'd not made the downloaded file executable. I now have by using: $ chmod +x ./VBoxFixHdd-Linux. The VM is now working:)

OSX ... I've changed the file to executable, yet I get the "Command not found" when launched. When I test it in finder, it acts as if executable. I'm launching it from within the HardDisks folder ... where I have the file.

[bobfitz]

Replying to bobfitz:

OSX ... I've changed the file to executable, yet I get the "Command not found" when launched. When I test it in finder, it acts as if executable. I'm launching it from within the HardDisks folder ... where I have the file.

Just for fun, I upgraded my VirtualBox 3.2.2 to 3.2.8 on my Ubuntu 10.04 machine. Windows XP loaded OK the first time. Ran Guest additions, rebooted, and the virtual drive was unavailable. This is exactly what happened on the Mac. After Guest additions was run, inacessible drive.

Now, I've downloaded the linux fix ... changed the file name to VBoxFixHdd ... used the chmod +x command to turn it into an executable file ... and attached it to the command line above. I get a "command not found" response, just like on the Mac. Here is my command from terminal:

bob@bob-laptop:~/Downloads$ sudo VBoxFixHdd --Windows XP.vdi ./VirtualBox/HardDisks/Windows XP.vdi --zeroparentuuid

I am obviously overlooking something. Any assistance would be appreciated.

[Andy]

Hi. I think it's your path that is the problem. If your VBoxFixHdd file is in your downloads folder then the path to your hard disks is probably wrong above. ./VirtualBox/HardDisks etc is a relative path assuming your VirtualBox folder is a subfolder of your Downloads folder, you might need to look at the full path or correct the relative path. Good luck.

Andy.

[bobfitz]

Replying to BritishAndy:

Hi. I think it's your path that is the problem.

Hi Andy ... thanks for your reply. While the example of the pathing may have been incorrect, I still get the "command not found" even when I copy the VBoxFixHdd executable file into the same folder as the .vdi files. This holds true both on the Ubuntu machine and on the Mac. See below ...

bob@bob-laptop:~/.VirtualBox/HardDisks$ ls VBoxFixHdd Windows XP.vdi bob@bob-laptop:~/.VirtualBox/HardDisks$ sudo VBoxFixHdd --Windows XP.vdi --zeroparentuuid sudo: VBoxFixHdd: command not found bob@bob-laptop:~/.VirtualBox/HardDisks$ sudo VBoxFixHdd --Windows XP.vdi .VirtualBox/HardDisks/Windows XP.vdi --zeroparentuuid sudo: VBoxFixHdd: command not found

I am appreciative of any assistance. As best I can tell, this command should work.

[bobfitz]

Let me clear up that copy from terminal ...

bob@bob-laptop:~/.VirtualBox/HardDisks$ ls VBoxFixHdd Windows XP.vdi

bob@bob-laptop:~/.VirtualBox/HardDisks$ sudo VBoxFixHdd --Windows XP.vdi --zeroparentuuid sudo: VBoxFixHdd: command not found

bob@bob-laptop:~/.VirtualBox/HardDisks$ sudo VBoxFixHdd --Windows XP.vdi .VirtualBox/HardDisks/Windows XP.vdi --zeroparentuuid sudo: VBoxFixHdd: command not found

[Andy]

I just managed to reproduce your issue on my Mac. I had to specify some path to the executable file, then it worked. Just './' in front of the command. Also, I am assuming your filename is 'Windows XP.VDI" so you'll need quotes to deal with the space. Try the following:

./VBoxFixHdd --filename "Windows XP.vdi" --zeroparentuuid

Andy.

[bobfitz]

Replying to BritishAndy:

I just managed to reproduce your issue on my Mac. I had to specify some path to the executable file, then it worked. Just './' in front of the command. Also, I am assuming your filename is 'Windows XP.VDI" so you'll need quotes to deal with the space. Try the following:

./VBoxFixHdd --filename "Windows XP.vdi" --zeroparentuuid

Andy

Thanks for the assistance, Andy. We're making some progress on the Ubuntu machine. I won't be able to work on the Mac until in the morning.

I ran the file as suggested, it actually DID something. I'll post a copy of the terminal screen below. Although the file did run, the Windows XP machine still was inacessible. What do you think? Do the results of the fix look correct?

Again, I appreciate anyone's input on this issue. It has to be resolvable!

bob@bob-laptop:~/.VirtualBox/HardDisks$ ls

VBoxFixHdd Windows XP.vdi

bob@bob-laptop:~/.VirtualBox/HardDisks$ ./VBoxFixHdd --filename "Windows XP.vdi" --zeroparentuuid

Old image UUID: ac715508-8386-439e-8c0a-831193f93790

Old parent UUID: 00000000-0000-0000-0000-000000000000

New parent UUID: 00000000-0000-0000-0000-000000000000

[Andy]

Hi, well done getting it working - that's the limit of my knowledge i'm afraid, I wouldn't know what the output strings should be, but like you said it can't be far off now. This did work for me, albeit in OS X. Stick with it. Andy.

[bobfitz]

Replying to BritishAndy:

I just managed to reproduce your issue on my Mac. I had to specify some path to the executable file, then it worked. Just './' in front of the command. Also, I am assuming your filename is 'Windows XP.VDI" so you'll need quotes to deal with the space. Try the following:

./VBoxFixHdd --filename "Windows XP.vdi" --zeroparentuuid

Andy.

Good morning folks ...

I was able to run the VBoxFixHdd program on the Mac, but the drive still shows inaccessible. It produced an output similar to the output from my Ubuntu machine (see comments above). I'll copy the output from the terminal below.

To summarize my issue ... I upgraded to VB 3.2.8 on a Mac and on a Linux machine. Both had .vdi files that were inaccessible; Windows 7 Ultimate 64-bit on the Mac ... Windows XP Home on the Ubuntu machine. I downloaded the appropriate version of VBoxFixHdd for each machine, changing them to executable files, and then copying them and launching them from the appropriate HardDisks folders. Both programs ran (after a little bit of adjusting) ... but both drives remain inaccessible within VirtualBox.

Here is the copy from the Mac's terminal ...

lts-macbook-pro:HardDisks lt$ ./VBoxFixHdd --filename "Windows 7 Ultimate 64 bit.vdi" --zeroparentuuid

Old image UUID: 967c2ad9-8fc9-4839-8683-bd622ed4aa19

Old parent UUID: 00000000-0000-0000-0000-000000000000

New parent UUID: 00000000-0000-0000-0000-000000000000

Again, I appreciate anyone's input, as I now how two machines down. Thanks!

[bobfitz]

FYI ... on the Ubuntu machine ... after running the VBoxFixHdd on the .vdi file ... this is what comes up with the VBoxManage list hdds

bob@bob-laptop:~$ VBoxManage list hdds

Oracle VM VirtualBox Command Line Management Interface Version 3.2.8 (C) 2005-2010 Oracle Corporation All rights reserved.

UUID: ac715508-8386-439e-8c0a-831193f93790

Parent UUID: base

Format: VDI

Location: /home/bob/.VirtualBox/HardDisks/Windows XP.vdi

State: created

Type: normal

Looks like it should work, but the drive is still listed as inaccessible.

[bobfitz]

Hi folks ...

A final word on my issues. After running the fix on both the Mac and the Ubuntu machines I still was unable to access the old hard drives. However, I was able to create new machines using the "fixed" .vdi files. Everything now works like a charm. I just deleted the old "inaccessible" machines.

This has been quite the pain for a simple upgrade. Hopefully others will gain from our issues and solutions.

Thanks again; especially to BritishAndy for your input.

[Andy]

Thanks for the thanks :-), I probably don't deserve it compared to the hard work constantly undertaken by the development community, however it is interesting that with the modern graphical front ends to OS X and Linux, that people like myself and possibly bob really have to work hard and well out of our comfort zone whenever a problem occurs outside of the gui wrappers around installs and upgrades. I am sure that that fixes and upgrades are well tested before release, but perhaps it is also true to say that the testers almost by definition are far too familiar with the product and complete numpties like myself make great beta testers :-) Keep up the good work. Andy.

[Fabiano R. Prestes]

Hi guys,

I am having the same problem but only with Windows VMs running XP 64 bits. I upgraded from 3.1.6 and the two XP64 boxes I have give out those messages. I have one XP 32 bits that upgraded normally, without even needing the tool to fix it. If I roll back to 3.1.6 they all run normally. If I try to upgrade again I get the error on the XP64 boxes again.

The host is running Debian Lenny 64 bits, plenty of RAM, plenty of disk, stable since version 2.2.2. Do you have any suggestions?

Thanks in advance!

[Klaus Espenlaub]

Replying to zosorock:

Hi guys,

I am having the same problem but only with Windows VMs running XP 64 bits. I upgraded from 3.1.6 and the two XP64 boxes I have give out those messages. I have one XP 32 bits that upgraded normally, without even needing the tool to fix it. If I roll back to 3.1.6 they all run normally. If I try to upgrade again I get the error on the XP64 boxes again.

The host is running Debian Lenny 64 bits, plenty of RAM, plenty of disk, stable since version 2.2.2. Do you have any suggestions?

Thanks in advance!

I don't understand - did you repair your affected base images with the tool mentioned above or not? Going back to a version which ignored this bad situation is just sticking the head in the sand...

[Fabiano R. Prestes]

hi Klaus,

I am sorry it was not clear. The tool does not do anything to my images. I just get a VERR_NO_TRANSLATION error and the tool exits.

I went back to 3.1.6 so I could continue using the machines until someone got back to me with a possible solution/suggestion.

Please let me know if you would like any other information.

Thank you!

[Fabiano R. Prestes]

Here is the actual message:

foguete:/# ./VBoxFixHdd-Linux --filename XP64.vdi --zeroparentuuid /VBoxFixHdd-Linux: error: VD: error VERR_NO_TRANSLATION opening image file 'XP64.vdi' /VBoxFixHdd-Linux: error: Cannot open the virtual disk image "XP64.vdi": VERR_NO_TRANSLATION

I have additionally tried to make a copy of the VDI on VB 3.1.6 and then use that new copy as the HD of the machine. Works fine. I then did the automated upgrade (via Synaptic) to 3.2.8 and got the same results: all machines work properly but the one running Windows XP 64 bits. Try to use the tool and get the result above.

I have officially run out of ideas. Any help is much appreciated.

[Klaus Espenlaub]

Not sure if 3.2.10 actually fixes anything, as to my knowledge 3.2.8 didn't introduce a "VERR_NO_TRANSLATION" regression. Haven't seen this error ever.

Could you attach the first few KB of the image which doesn't work? You can do this with "dd if=/path/to/XP64.vdi of=/path/to/header.bin bs=4K count=1"

With that information I can try figuring out what your problem actually is.

[Mr.Snipfold]

3.2.10 - Problem resolved. Thanx for support.