virtualbox.org

Ugh. I'm blocked...

Host system is OS X 10.7.5 (atop an Ivy Bridge MBP15)

Just updated from "10.7.5 - one dot rev" (machine is current but I heard that there have been a few "touchy" dot revs between Apple and vbox of late so I've waited on until today)
Just upgraded from vbox 4.1.x to 4.2.1
Updated to 4.2's extension pack

Issue: My Win7 VM/vhd won't boot (it does the following)...

1) Launch vbox Manager;
2) Double click to select/boot my Win7 VM;
3) VirtualBox host window displays/paints (with the Press F12 to select boot device, etc.);
4) VirtualBox host window auto-closes and a second (host?) window appears (never noticed this one before);
5) Window from #4 remains in (what I can only describe as a) a pre-POST like state (black console with a non-blinking white cursor);

Result: No disk access, etc. It just sits there. Need to use the OS X window close icon (thence power down/off) to exit (something I've done perhaps a dozen times now).

Did I miss something about this update? Do I need to run this atop the latest, hottest Mountain Lion?

Deeper detail...
The 4.1.2x to 4.2.1 update process went EXACTLY like this (and probably falls outside of some test scenerio)...

1) Use Apple's OS X Software Update service (a la Windows Update) to jump from 10.7.x to 10.7.5 (my EFI did not appear to need an update but the update process did leave a shell alive after the installation, recycle, etc.);
2) Check for updates again, found and installed Safari 6;
3) Install vbox 4.2.1 (double click to run the installer, etc.) ... atop an existing 4.1.2x /w extension pack;
4) Forgetting to install the 4.2 extension pack, attempted to launch my (now broken) VM (vbox bitched at me and refused to launch the VM for reasons that I'm sure make sense);
5) Downloaded the WRONG extension pack (because the virtualbox.org downloads page's formatting/emphasis misled me) and attempted to install that (the installer or vbox Manager bitched and refused to install after I confirmed acceptance of license);
6) Downloaded and installed 4.2's extension pack (no issues occurred during install);
7) Tried to launch my vhd-based VM (with symptoms previously described).

A secondary XP VM boots (atop this kit) just fine BUT that VM does not use any advanced USB functionality, etc.

Disabled/removed the advanced (i.e., extension pack sensitive) USB settings and Shared folders settings from the Win7 VM;
9) Tried again to boot the Win7 VM (no change).

Ideas?
Anyone seen this behavior?
Is this just the behavior one gets when the boot volume cannot be found?

Please advise...

Solved (by self).

Somehow during the update VB lost control over where my .vhd was. The Manager UI (which tends to have "(de)coupling from actual state" issues) displayed that the .vhd was known and available (within Storage) just as before the update. But the Manager UI *lied*.

Having seen stuff like this before, I deleted the existing bindings (from Storage) and re-added a (NULL) DVD device to the IDE controller and my .vhd file (to existing SATA controller as a SSD disk).

Now VB finds and boots from the .vhd (again).

This is probably (yet another) bug whereby the vm's .xml becomes mangled and/or the VB Manager UI fails to properly display what it *actually* read/loaded (displaying some old, stale state from a (buggy) cache / controller?).

Cheers...

vbox_user1001 wrote:This is probably (yet another) bug whereby the vm's .xml becomes mangled and/or the VB Manager UI fails to properly display what it *actually* read/loaded (displaying some old, stale state from a (buggy) cache / controller?).

The VBoxSVC process keeps track of all the settings. The VM Manager will show what VBoxService tells it. It is normal for the on-disk XML file to be out of sync with running VBoxSVC, however when the VBoxSVC process terminates (normally that happens automatically a few seconds after the last running client is closed, be it a VM, the VM Manager, or some other client), it should update the on-disk settings file.

If you have a reproducible scenario where the on-disk file gets out of sync with VBoxSVC (which does not include forcibly killing VBoxSVC, manually editing files, or similar), then please create a ticket on the public bug tracker and describe the steps required to reproduce the problem.