hard drive not accessible when upgrading to 2.1.4
Posted: 8. Apr 2009, 20:15
Ok before anyone asks, no, I didn't save any log files to post. I upgraded from 1.5.6 to 2.1.4 and encountered a nasty problem with not being able to access the primary hard drive image (Ubuntu 8.04 host, Windows XP SP3 guest). A slave drive image was fine, and this same upgrade on other machines went without a hitch. The upgrade complains that it can't access the image, and I get a VERR_NOT_SUPPORTED error when I remove and try to re-add the image to the disk manager. If I uninstall 2.1.4 and re-install 1.5.6, all is well and the guest boots fine. I searched, in vain, all over the bug tracker, forums, and Google, and can't seem to find anyone else who's encountered this problem. I did find several instances where people had trouble cloning a drive, but I'm not wanting to clone. I simply want to upgrade. For grins, I did try to clone the drive image, and under 1.5.6, I get a VERR_EOF error and it fails. Under 2.1.4, it won't even attempt to read the image and fails right away with the VERR_NOT_SUPPORTED error. Under 1.5.6, though, the image boots just fine, I can read and write to it just fine. As I said, I only encountered this problem on one of about 5 machines running VirtualBox. If it's any consequence, all of the hosts are Linux (Ubuntu 8.04) except for one Windows XP host, and all are running Linux or other non-Windows guest OS' except for this one problem child. Also, the drive image is an expanding one and not a fixed one, though it's nearly grown to it's full size on the host.
Anyway, the point of my post is to get something out there with all the VERR_xxx keywords so the next poor sap who runs into this can hopefully find this and not feel all alone. After a pot of coffee and watching the sun come up, and trying a million things that didn't work, I got my issue resolved. But, I didn't save any logs because I installed and uninstalled multiple versions of VirtualBox in the process of trying to save this guest OS. Here's what I ended up doing:
- Under the old, *working* version of VirtualBox (1.5.6), I mounted a SystemRescueCD iso image and booted the guest. I used the rescue cd to create an image of the problem hard drive and stored it on the network (using partimage).
- I installed VirtualBox 2.1.4, which in turn uninstalled 1.5.6 and upgraded all the configuration files. I got the usual error message about this one image, so I went into the drive manager and released and removed (deleted) the faulty image.
- I created a brand new, empty vdi file of the same size, though this time I hedged my bets and made it fixed (not expanding), just in case.
- Mounted the rescue iso once again, booted the vm, and used fdisk to create a bootable NTFS partition, and used partimage to restore my saved partition.
- I forgot to save off the MBR when I originally saved, so I ended up having to mount an XP iso, booting off that into the recovery console, and running FIXMBR.
- Unmounted all the iso's and all is well and running under 2.1.4
I didn't file a bug report because honestly, I couldn't reproduce this if I tried. Maybe it's just me with an oddly corrupted vdi (that somehow worked under 1.5.6), or maybe there's a weird bug that under just the right conditions pops it's ugly head up. Either way, maybe this will help someone else.
-tim
Anyway, the point of my post is to get something out there with all the VERR_xxx keywords so the next poor sap who runs into this can hopefully find this and not feel all alone. After a pot of coffee and watching the sun come up, and trying a million things that didn't work, I got my issue resolved. But, I didn't save any logs because I installed and uninstalled multiple versions of VirtualBox in the process of trying to save this guest OS. Here's what I ended up doing:
- Under the old, *working* version of VirtualBox (1.5.6), I mounted a SystemRescueCD iso image and booted the guest. I used the rescue cd to create an image of the problem hard drive and stored it on the network (using partimage).
- I installed VirtualBox 2.1.4, which in turn uninstalled 1.5.6 and upgraded all the configuration files. I got the usual error message about this one image, so I went into the drive manager and released and removed (deleted) the faulty image.
- I created a brand new, empty vdi file of the same size, though this time I hedged my bets and made it fixed (not expanding), just in case.
- Mounted the rescue iso once again, booted the vm, and used fdisk to create a bootable NTFS partition, and used partimage to restore my saved partition.
- I forgot to save off the MBR when I originally saved, so I ended up having to mount an XP iso, booting off that into the recovery console, and running FIXMBR.
- Unmounted all the iso's and all is well and running under 2.1.4
I didn't file a bug report because honestly, I couldn't reproduce this if I tried. Maybe it's just me with an oddly corrupted vdi (that somehow worked under 1.5.6), or maybe there's a weird bug that under just the right conditions pops it's ugly head up. Either way, maybe this will help someone else.
-tim
