VirtualBox Failed to Open Session

[Geometrian]

Hi,

I just finished a massive ordeal of setting up my OS to use GrUB Legacy on a flat HDD image instead of a CD iso. The solution is not ideal, but it's satisfactory for now.

My OS now boots successfully on Bochs and on real hardware. Unfortunately, on VirtualBox, where it used to work, I'm getting an error: VirtualBox failed to open session:

I don't know what this could be, and the references online only reference professional OSes.

The kernel still has everything linked into it, but for testing purposes I changed it to only write a single line of text in text mode and then hang. The VMDK is created with this shell script from the flat disk image:

Code: Select all

#http://stackoverflow.com/questions/454899/how-to-convert-flat-raw-disk-image-to-vmdk-for-virtualbox-or-vmplayer
qemu-img convert -O vmdk build/moss-disk.bin ../VM/MOSS-disk-flat.vmdk

If you need more information, the updated source is in my signature, the flat binary is here (~50MiB), and the VMDK is here (~2MiB).

Thanks,

[Geometrian]

Ack. Well, I updated VirtualBox two minor revisions and remade the VM. At least one of those seems to have fixed it somehow.
EDIT: Well now it's being sporadic. Trying to track it down, but any hints would still be nice.

[Geometrian]

I don't know exactly why this is happening, but I have a theory, and a tentative solution.

Unlike for CDs, VirtualBox keeps close tabs on the UUID of virtual hard disks. Why, I don't know. I have found that removing the HDD file from the list of known media (also has the effect of removing from the VM) and then adding it back fixes the problem--this, since it updates the cache of the UUID of whatever VirtualBox had previously.

That's annoying to do each time, so I wrote a Python script, which should be easily adaptable. All it does is change the UUID of the disk image to match whatever VirtualBox was expecting:

Code: Select all

from subprocess import call
call([
    "C:\\Program Files\\Oracle\\VirtualBox\\VBoxManage.exe",
    "internalcommands","sethduuid","C:\\dev\\C++\\MOSS\\VM\\MOSS-disk-flat.vmdk","4bfe659c-0e11-4f5f-a046-491451411217"
])
call([
    "C:\\Program Files\\Oracle\\VirtualBox\\VBoxManage.exe",
    "startvm","MOSS"
])

I don't know if this qualifies as a bug in VirtualBox. I kindof think it does, since a broken UUID shouldn't cause a crash with no output, but I don't know.

-G

[Kazinsal]

I have a feeling that the method you use to manipulate the hard disk image and re-convert to VMDK modifies the image's UUID, throwing VirtualBox out of whack.

[Geometrian]

Aye. "qemu-img convert" seems to make the UUID all zeroes. I edited my previous post slightly: just because the UUID isn't what VirtualBox expected, I would think it oughtn't to crash.

[dozniak]

That's why an ISO is a much better idea if you change the OS image often.

You can create the harddrive once and mount it, but boot from the cdrom image, this requires no tricks, only restarting the VM.