OSDev.org

Posted: **Tue Jul 16, 2013 1:47 am**

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,

Posted: **Tue Jul 16, 2013 1:56 am**

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.

Posted: **Tue Jul 16, 2013 4:01 pm**

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

Posted: **Tue Jul 16, 2013 4:25 pm**

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.

Posted: **Tue Jul 16, 2013 4:39 pm**

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.

Posted: **Wed Jul 17, 2013 1:19 am**

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.

OSDev.org

VirtualBox Failed to Open Session

VirtualBox Failed to Open Session

Re: VirtualBox Failed to Open Session

Re: VirtualBox Failed to Open Session

Re: VirtualBox Failed to Open Session

Re: VirtualBox Failed to Open Session

Re: VirtualBox Failed to Open Session