I'm so close that I can taste it...
I set up launchers for a couple of my existing VirtualBox VMs, including giving each its own vm_fs. I also converted my disk files from dynamic to fixed. The window opens up, but the contents stay black, and the following items are put in the log:
[runtime -> vbox_labyrinth -> vbox] Error: ioctl operation=33
[runtime -> vbox_labyrinth -> vbox] Error: void ioctl(SUPCALLVMMR0&) called (/data/depot/genodelabs/src/vbox6/2024-04-11/src/virtualbox6/sup.cc:666), not implemented, eip=0x1a46715
My only guess is that something about the way I've configured the VM triggers this, but I haven't been able to dig deeper. Does anyone have any thoughts on this?
I then tried to use Seoul, but my ignorance got in the way of this one. How do I configure the "vdi_block" component to point to my disk file (not named "block.vdi")?
Thanks in advance for any advice!
Happy Sculpting!
Hello,
On 18.05.24 07:44, John J. Karcher wrote:
I'm so close that I can taste it...
I set up launchers for a couple of my existing VirtualBox VMs, including giving each its own vm_fs. I also converted my disk files from dynamic to fixed. The window opens up, but the contents stay black, and the following items are put in the log:
[runtime -> vbox_labyrinth -> vbox] Error: ioctl operation=33
[runtime -> vbox_labyrinth -> vbox] Error: void ioctl(SUPCALLVMMR0&) called (/data/depot/genodelabs/src/vbox6/2024-04-11/src/virtualbox6/sup.cc:666), not implemented, eip=0x1a46715
My only guess is that something about the way I've configured the VM triggers this, but I haven't been able to dig deeper. Does anyone have any thoughts on this?
I can only suggest to compare your .vbox6 file to depot/genodelabs/raw/vbox6/<date>/machine.vbox6. It happened more than one time that a subtle mistake make vbox6 unhappy for some of us. (as example https://lists.genode.org/mailman3/hyperkitty/list/users@lists.genode.org/thr...)
I then tried to use Seoul, but my ignorance got in the way of this one. How do I configure the "vdi_block" component to point to my disk file (not named "block.vdi")?
Renaming your vdi to block.vdi would be the easiest way (and potentially adjusting your .vbox file to point to your renamed block.vdi file).
Beside that, you may create a custom launcher and replace the occurrence of block.vdi with your desired vdi file name. To do so, start a vdi_block instance, copy the resulting xml vdi_block text from config/managed/runtime to your new launcher file. Replace in the file the xml node "start" with "launcher", e.g. <start ...> ... /start> -> <launcher ...> ... /launcher>. Finally, replace the occurrences of block.vdi with another file name you desire.
Cheers,
Alex.
On 5/18/24 10:51 AM, Alexander Boettcher wrote:
Hello,
On 18.05.24 07:44, John J. Karcher wrote:
I'm so close that I can taste it...
I set up launchers for a couple of my existing VirtualBox VMs, including giving each its own vm_fs. I also converted my disk files from dynamic to fixed. The window opens up, but the contents stay black, and the following items are put in the log:
[snip]
I can only suggest to compare your .vbox6 file to depot/genodelabs/raw/ vbox6/<date>/machine.vbox6. It happened more than one time that a subtle mistake make vbox6 unhappy for some of us. (as example https:// lists.genode.org/mailman3/hyperkitty/list/users@lists.genode.org/thread/ ISG37EHECREYJCF4WOKLFPAV2NMHXSG7)
After some trial-and-error, I discovered that using the "USBTablet" for the pointing device causes this ioctl 33 error - switching to "PS2Mouse" causes it to work fine! Good to note for anyone else trying this.
This is very exciting! I just need to figure out how to share files, which I currently do using an NFS share on the Linux host. I'd like to avoid VBox shared folders, since I want it to work with Seoul also, so I might just have to boot my "host" Linux OS directly from the partition, until I can migrate that function somewhere else.
I then tried to use Seoul, but my ignorance got in the way of this one. How do I configure the "vdi_block" component to point to my disk file (not named "block.vdi")?
Renaming your vdi to block.vdi would be the easiest way (and potentially adjusting your .vbox file to point to your renamed block.vdi file).
Beside that, you may create a custom launcher and replace the occurrence of block.vdi with your desired vdi file name. To do so, start a vdi_block instance, copy the resulting xml vdi_block text from config/ managed/runtime to your new launcher file. Replace in the file the xml node "start" with "launcher", e.g. <start ...> ... /start> -> <launcher ...> ... /launcher>. Finally, replace the occurrences of block.vdi with another file name you desire.
I don't want to rename all my VDI files, so I did this, but I seem to be missing something. (I am still at the kindergarten level with these config files.)
Here is my example:
<launcher name="vdi_block_abc" pkg="alex-ab/pkg/vdi_block/2024-04-09"> <route> <service name="File_system" label="ABC-disk1.vdi"> <child name="vm_fs_abc"/> </service> </route> </launcher>
If I use "block.vdi" for the label, it doesn't complain, but it can't find the file. If I use it as above, it fails to load because of missing "block.vdi". ("vm_fs_abc" points to the correct directory, and works with VBox.)
Am I on the right track? Do I need to add a <config> node or something?
Thanks a million! -- John J. Karcher devuser@alternateapproach.com
Hello,
On 24.05.24 00:59, John J. Karcher wrote:
Beside that, you may create a custom launcher and replace the occurrence of block.vdi with your desired vdi file name. To do so, start a vdi_block instance, copy the resulting xml vdi_block text from config/ managed/runtime to your new launcher file. Replace in the file the xml node "start" with "launcher", e.g. <start ...> ... /start> -> <launcher ...> ... /launcher>. Finally, replace the occurrences of block.vdi with another file name you desire.
I don't want to rename all my VDI files, so I did this, but I seem to be missing something. (I am still at the kindergarten level with these config files.)
Here is my example:
<launcher name="vdi_block_abc" pkg="alex-ab/pkg/vdi_block/2024-04-09"> <route> <service name="File_system" label="ABC-disk1.vdi"> <child name="vm_fs_abc"/> </service> </route> </launcher>
If I use "block.vdi" for the label, it doesn't complain, but it can't find the file. If I use it as above, it fails to load because of missing "block.vdi". ("vm_fs_abc" points to the correct directory, and works with VBox.)
Am I on the right track? Do I need to add a <config> node or something?
just using the Genode re-label mechanism will not work. Inside the established file system session, the file name is actually requested, which is not rewriteable from the outside.
So, indeed, you have to change the config of the vdi_block, that is why I suggested to look into config/managed/_runtime_ instead of config/managed/deploy, the former contains the config snipped.
I crafted a config on a ram_fs and it looks like follows. Additionally, I removed the <import...> node and named the Filesystem label a bit more obvious, just to avoid confusion. The import node is only required to import a new empty block.vdi if it does not exists, which you don't desire/require in your case.
<launcher pkg="alex-ab/pkg/vdi_block/2024-04-09" priority="-2"> <config file="/your.vdi" writeable="yes"> <vfs> <fs label="fs_vdi" buffer_size="2M"/> </vfs> </config> <route> <service name="File_system" label="fs_vdi"> <child name="ram_fs"/> </service> </route> </launcher>
Hope it helps,
Alex.
On 5/24/24 2:33 AM, Alexander Boettcher wrote:
Hello,
On 24.05.24 00:59, John J. Karcher wrote:
Beside that, you may create a custom launcher and replace the occurrence of block.vdi with your desired vdi file name. To do so, start a vdi_block instance, copy the resulting xml vdi_block text from config/ managed/runtime to your new launcher file. Replace in the file the xml node "start" with "launcher", e.g. <start ...> ... / start> -> <launcher ...> ... /launcher>. Finally, replace the occurrences of block.vdi with another file name you desire.
I don't want to rename all my VDI files, so I did this, but I seem to be missing something. (I am still at the kindergarten level with these config files.)
Here is my example:
<launcher name="vdi_block_abc" pkg="alex-ab/pkg/vdi_block/2024-04-09"> <route> <service name="File_system" label="ABC-disk1.vdi"> <child name="vm_fs_abc"/> </service> </route> </launcher>
[snip]
Am I on the right track? Do I need to add a <config> node or something?
just using the Genode re-label mechanism will not work. Inside the established file system session, the file name is actually requested, which is not rewriteable from the outside.
So, indeed, you have to change the config of the vdi_block, that is why I suggested to look into config/managed/_runtime_ instead of config/ managed/deploy, the former contains the config snipped.
I crafted a config on a ram_fs and it looks like follows. Additionally, I removed the <import...> node and named the Filesystem label a bit more obvious, just to avoid confusion. The import node is only required to import a new empty block.vdi if it does not exists, which you don't desire/require in your case.
<launcher pkg="alex-ab/pkg/vdi_block/2024-04-09" priority="-2"> <config file="/your.vdi" writeable="yes"> <vfs> <fs label="fs_vdi" buffer_size="2M"/> </vfs> </config> <route> <service name="File_system" label="fs_vdi"> <child name="ram_fs"/> </service> </route> </launcher>
That worked - thanks another million! Now I can run the same VM three ways - Linux/VBox, Genode/VBox, and Gendode/Seoul - very nifty!
In Seoul, there is no audio, but that's probably because the VM isn't configured for VirtIO audio; your pre-built VMs work fine.
FWIW, my top feature request for Seoul would probably be copy/paste, which is universally useful, followed by shared folder support, which I can work around.
(And sorry for the poor reading comprehension. But I left the above long-winded quote intact because I suspect it may be useful in the archives for someone else.)
It looks like I am only one step away from being able to switch to Genode full-time. Consider this a warning - real "user" questions are coming soon! ;^)
Happy Sculpting!
John J. Karcher devuser@alternateapproach.com
Hello,
On 28.05.24 07:01, John J. Karcher wrote:
On 5/24/24 2:33 AM, Alexander Boettcher wrote:
Hello,
On 24.05.24 00:59, John J. Karcher wrote:
Beside that, you may create a custom launcher and replace the occurrence of block.vdi with your desired vdi file name. To do so, start a vdi_block instance, copy the resulting xml vdi_block text from config/ managed/runtime to your new launcher file. Replace in the file the xml node "start" with "launcher", e.g. <start ...> ... / start> -> <launcher ...> ... /launcher>. Finally, replace the occurrences of block.vdi with another file name you desire.
I don't want to rename all my VDI files, so I did this, but I seem to be missing something. (I am still at the kindergarten level with these config files.)
Here is my example:
<launcher name="vdi_block_abc" pkg="alex-ab/pkg/vdi_block/2024-04-09"> <route> <service name="File_system" label="ABC-disk1.vdi"> <child name="vm_fs_abc"/> </service> </route> </launcher>
[snip]
Am I on the right track? Do I need to add a <config> node or something?
just using the Genode re-label mechanism will not work. Inside the established file system session, the file name is actually requested, which is not rewriteable from the outside.
So, indeed, you have to change the config of the vdi_block, that is why I suggested to look into config/managed/_runtime_ instead of config/ managed/deploy, the former contains the config snipped.
I crafted a config on a ram_fs and it looks like follows. Additionally, I removed the <import...> node and named the Filesystem label a bit more obvious, just to avoid confusion. The import node is only required to import a new empty block.vdi if it does not exists, which you don't desire/require in your case.
<launcher pkg="alex-ab/pkg/vdi_block/2024-04-09" priority="-2"> <config file="/your.vdi" writeable="yes"> <vfs> <fs label="fs_vdi" buffer_size="2M"/> </vfs> </config> <route> <service name="File_system" label="fs_vdi"> <child name="ram_fs"/> </service> </route> </launcher>
That worked - thanks another million! Now I can run the same VM three ways - Linux/VBox, Genode/VBox, and Gendode/Seoul - very nifty!
In Seoul, there is no audio, but that's probably because the VM isn't configured for VirtIO audio; your pre-built VMs work fine.
Which Seoul packet you are using ? I solely added audio support to seoul-block-audio, all the other variants have no audio model configured, just because I did not required it by now. But you are of course also right, that the VM has to have the virtio driver for audio also running.
FWIW, my top feature request for Seoul would probably be copy/paste, which is universally useful, followed by shared folder support, which I can work around.
As written earlier, the path is clear how to do that, it is a matter of having time for that.
Cheers,
Alex.
On 5/29/24 2:34 AM, Alexander Boettcher wrote:
Hello,
[snip]
In Seoul, there is no audio, but that's probably because the VM isn't configured for VirtIO audio; your pre-built VMs work fine.
Which Seoul packet you are using ? I solely added audio support to seoul-block-audio, all the other variants have no audio model configured, just because I did not required it by now. But you are of course also right, that the VM has to have the virtio driver for audio also running.
I am using "<launcher pkg="alex-ab/pkg/seoul-block-audio/2024-04-09">". I'm pretty sure it's just the misconfigured VM, because the CPU runs very hard for no reason, which I assume is because of a driver mismatch.
This is not a problem, since most of my VMs don't require audio, and the ultimate goal is to move as many functions as possible into native Genode packages anyway!
FWIW, my top feature request for Seoul would probably be copy/paste, which is universally useful, followed by shared folder support, which I can work around.
As written earlier, the path is clear how to do that, it is a matter of having time for that.
No pressure from me - just one end user's opinion. ;^)
Happy Sculpting!
John J. Karcher devuser@alternateapproach.com
-
Alexander Boettcher -
John J. Karcher