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.