Troubleshooting virtualbox startup

I’m trying to configure VM that would be able to run my natively installed Ubuntu.

During attempt to start vm I get:

Error: machine could not enter running state
Error: Could not open the medium '//linux.vmdk'.
VD: error VERR_FILE_NOT_FOUND opening image file '//linux.vmdk' (VERR_FILE_NOT_FOUND)

I know that linux.vmdk name comes from /rw/vm/debian/machine.vbox6 from location="linux.vmdk" attribute in HardDisk definition. If I put there an absolute path then two initial slashes are not added to the path. I have tried different values there (/linux.vmdk, /shared/linux.vmdk, /debian/linux.vmdk) and copied linux.vmdk and accompanying linux-pt.vmdk file to different locations (rw/vm/debian, /rw/vm, /rw/shared`), but I can’t eliminate this error.

Source for above errors in logs is: [runtime -> ubuntu_vm -> vbox] (where ubuntu_vm is my launcher name), so I assume that filesystem that is visible for virtualbox is defined by start -> config -> vfs node for vbox in runtime file in package. I believe I have modified there only content of dev directory, so vm filesystem should be accessible as / and shared in /shared.

How can I easily debug what files are accessible in specific vfs configuration? Is there some small component that would allow to inspect this?

Do you have any idea, where did I make a mistake with this configuration?

We had in the past also the case, that when the referenced /dev/* block device in your vmdk does not exists for some reasons, VBox falsely claim that the vmdk file can not be opened (but it just couldn’t open the block device).

You may also try check the thread of the mailing list for ideas: Virtualvox6 and two raw partitions - users - lists.genode.org

Thanks Alex for the hint.

I suspected that I may have broken some other configuration, but since after changing name of vmdk file to something definitely not existing I got the same error, I thought that maybe this file is really not being found.

I’ll try to review my whole configuration to understand where the issue may come from.

Hi tomga, did you check that the UUID in the vmdk file matches with the UUID of linux.vmdk in your machine.vbox6?

As a side note, the default /vm/debian/ path on the file system is set by the vm_fs launcher. This chroot is usually passed into Virtualbox as vm file system. Therefore, provided you are using the vm launcher and your VMDK file is at /vm/debian/linux.vmdk in the specifying location="linux.vmdk" or location="/linux.vmdk" should yield the same result, as Virtualbox sees /vm/debian/ as the root of your file system.

Thank you @atopia for the hints.

Regarding /vm/debian path being served by vm_fs launcher, I remembered myself that I found this information long time ago, but since recall_fs like behavior was somehow so natural I forgot about it.

Following your second suggestion, I have verified that uuids are in sync in linux.vmdk and machine.vbox6 files.

Unfortunately I did not succeed until now. But I have two potential ideas for continuation.

I’m trying to follow Start existing linux from sculpt by Johannes Shlatow. And my first doubt is that my adaptations in the launcher file may be wrong (or incomplete). I have changed routing from:

     <service name="Block" label_suffix=" -> 4">
       <child name="nvme-0.part_block" label="4"/>
     </service>

to

     <service name="Block" label_suffix=" -> 4">
       <child name="ahci-0.part" label="4"/>
     </service>

I can see similar routing for my used partition in /config/managed/runtime but I’m not sure if those block devices are exposed to deploy subsystem. Even if it is wrong I would expect to see some error about service being unavailable or similar, but I don’t.

Second idea is that when virtualbox starts it prints information about some log file being created:

[runtime -> _ubuntu@virtualbox -> vbox] main     Log created: 2024-11-26T19:28:12.000000000Z

Do you know where can I find it or change some configuration so I can access it? Maybe my hopes are wrong but maybe there would be some better info about the problem.

Full log for virtualbox start attempt is below (I found an ugly workaround for getting logs into the firefox in seoul vm, so I can share them here :slight_smile: ). Maybe something will be obvious for one of you.

^M[runtime -> _ubuntu@virtualbox -> vbox]   0x48b0000 .. 0x4906fff: virtualbox6-shaderlib.lib.so^[[0m
^M[runtime -> _ubuntu@virtualbox -> vbox]   0x10ce2000 .. 0x10d14fff: vfs_oss.lib.so^[[0m
^M[runtime -> _ubuntu@virtualbox -> vbox] OSS: verbose: 0 play_enabled: 1 min_ofrag_size: 8192 max_ofrag_size: 8192 record_enabled: 1 min_ifrag_size: 8192 max_ifrag_size: 8192 min_sample_rate: 8000 max_sample_rate: 48000 ^[[0m
^M[runtime -> _ubuntu@virtualbox -> vbox]   0x10ccd000 .. 0x10ce1fff: vfs_pipe.lib.so^[[0m
^M[runtime -> _ubuntu@virtualbox -> vbox] main     Log created: 2024-11-26T19:28:12.000000000Z
^M[runtime -> _ubuntu@virtualbox -> vbox] main     Process ID:  0 (0x0)
^M[runtime -> _ubuntu@virtualbox -> vbox] main     Parent PID:  -1 (0xffffffff)
^M[runtime -> _ubuntu@virtualbox -> vbox] main     Executable:  /virtualbox6
^M[runtime -> _ubuntu@virtualbox -> vbox] ^[[31mError: machine could not enter running state^[[0m
^M[runtime -> _ubuntu@virtualbox -> vbox] Error: Could not open the medium '//linux.vmdk'.
^M[runtime -> _ubuntu@virtualbox -> vbox] VD: error VERR_FILE_NOT_FOUND opening image file '//linux.vmdk' (VERR_FILE_NOT_FOUND)^[[0m
^M[runtime -> _ubuntu@virtualbox -> vbox] main
^M[runtime -> _ubuntu@virtualbox -> vbox] main     !!Assertion Failed!!
^M[runtime -> _ubuntu@virtualbox -> vbox] main     Expression: state <= 1 && ( (state == 0 && count == 0) || (state == 1 && count < PR_UINT32_MAX/2))
^M[runtime -> _ubuntu@virtualbox -> vbox] main     Location  : /data/depot/genodelabs/src/vbox6/2024-10-07/src/virtualbox6/VBoxAPIWrap/MachineWrap.cpp(11269) virtual nsrefcnt MachineWrap::AddRef()
^M[runtime -> _ubuntu@virtualbox -> vbox] main     Stack     :
^M[runtime -> _ubuntu@virtualbox -> vbox] main     000000000192ce9b
^M[runtime -> _ubuntu@virtualbox -> vbox] main
^M[runtime -> _ubuntu@virtualbox -> vbox]
^M[runtime -> _ubuntu@virtualbox -> vbox] !!Assertion Failed!!
^M[runtime -> _ubuntu@virtualbox -> vbox] Expression: state <= 1 && ( (state == 0 && count == 0) || (state == 1 && count < PR_UINT32_MAX/2))
^M[runtime -> _ubuntu@virtualbox -> vbox] Location  : /data/depot/genodelabs/src/vbox6/2024-10-07/src/virtualbox6/VBoxAPIWrap/MachineWrap.cpp(11269) virtual nsrefcnt MachineWrap::AddRef()
^M[runtime -> _ubuntu@virtualbox -> vbox] Stack     :
^M[runtime -> _ubuntu@virtualbox -> vbox] 000000000192ce9b
^M[runtime -> _ubuntu@virtualbox -> vbox]
^M[runtime -> _ubuntu@virtualbox -> vbox] main     AddRef: illegal refcnt=3221225469 state=2
^M[runtime -> _ubuntu@virtualbox -> vbox] AddRef: illegal refcnt=3221225469 state=2
^M[runtime -> _ubuntu@virtualbox -> vbox] ^[[31mError: Uncaught exception of type 'Genode::Ipc_error'^[[0m
^M[runtime -> _ubuntu@virtualbox -> vbox] ^[[34mWarning: abort called - thread: main^[[0m
^M[core] ^[[34mWarning: unresolvable exception 3, pd 'init -> runtime -> _ubuntu@virtualbox -> vbox', thread 'ep', cpu 0, ip=0x11ae8af sp=0x403fe080 bp=0xbffffffd no signal handler^[[0m
^

I see now in top_view that all:

  • ahci-0.part (provider of partition block services)
  • ahci-0.5.fs (client for my used partition for Sculpt
  • my _ubuntu@virtualbox

are all in init -> runtime so there should be no issues with accessing this service, so probably my first idea in previous post is wrong.

I have managed to eliminate error about missing linux.vmdk file.

It was a silly mistake on my side. I forgot about -relative parameter when calling VBoxManage command. This caused partitions to relate to /dev/sda inside linux.vmdk file but I have provided in vfs dev files for partitions (e.g. /dev/sda1). Of course error message did not help.

It is a step forward but I still can’t boot the system. Currently no sign of life in virtual box window. Hopefully I’ll be able to progress in next days.

I have another update on the progress of this endeavor. It is a report about almost complete success.

Like I reported last time, after resolving issues with loading of linux.vmdk file, I was still in a state when there was no sign of life in virtualbox window (apart from the window showing up on a desktop). Since I did not have any clue about the source of a problem, I’ve decided to go back and start again from the beginning from some working state. I have downloaded debian vm using download_debian package from cnuke’s depot, checked that it works and started to apply changes incrementally. After each change I have tested if it did not break anything.

With this strategy, after few hours, I was able to boot successfully my linux (Ubuntu) in a virtualbox in Sculpt. My suggestion for anyone else attempting to do a similar task is to do it the same way. It is much easier to troubleshoot when you know exactly what change caused a breakage.

Now I have observed two issues when using this vm.

First is that audio does not work. In machine.vbox6 I can see:

<AudioAdapter controller="HDA" driver="OSS"/>

in <Hardware> section, and I have configured routing to Record and Play services to mixer, but my Ubuntu in a Virtualbox does not see any audio device available. Does anyone know what could be a reason? Should I change emulated audio device to something else? Or should I even expect it to work?

Another thing that I have observed is most probably not related to vm but as far as I know I can observe result only inside it. The issue is that when I suspend Sculpt and resume later, and I start my Ubuntu in a vm, the time in a vm is delayed. I suspect that after resume Rtc service provider (system_clock) does not update itself to reflect current time. However, I don’t know if it is expected to do so, or maybe I should start some other Rtc provider which would do. Do I correctly guess what the problem is? And what is the expected behavior in this case?

Does anyone know what could be a reason? Should I change emulated audio device to something else? Or should I even expect it to work?

Using HDA is fine but you need to enable the audio support explicitly via

<AudioAdapter controller="HDA" driver="OSS" enabled="true" enabledIn="true" enabledOut="true"/>

When you start to play something in the VM the OSS plugin will open the Play session and you can monitor that by looking into /report/runtime/mixer/state that should report a similar state:

<state>
  <play label="vm_name -> right"/>
  <play label="vm_name -> left"/>
  <play label="audio -> mic_right"/>
  <play label="audio -> mic_left"/>
  <record label="audio -> right"/>
  <record label="audio -> left"/>
</state>
1 Like

Thank you Josef.

I was able to enable sound from virtualbox. And actually when playing something, the report file contains information about it.

I did only one quick test with some video from youtube in firefox, and although I could hear something there was no way to understand anything. I can try to help by providing additional information or check some options, if it is unexpected behavior with current implementation.

For comparison, I can say that the same youtube video sounds very well on tiny core seoul audio in firefox.

I think that I have found an answer for this by myself. Sculpt documentation mentions only NVMe, AHCI and GPU drivers as suspend-resume aware, so probably Rtc is still waiting in a queue.

I did only one quick test with some video from youtube in firefox, and although I could hear something there was no way to understand anything. I can try to help by providing additional information or check some options, if it is unexpected behavior with current implementation.

It is supposed to work, yes - we regularly test Ubuntu 22.04 and Windows 10 (and I am personally running Void Linux). Can you elaborate on the nature of the malfunction, i.e. is it scrambled, barely audible or seems to be interrupted during playback?

I don’t know what was the reason for this issue yesterday, but today it seems to work ok. I’ll try to observe this if it happens again and will try to correlate it with my other activities.

Regarding the nature of the problem that I experienced yesterday, it was like most of “sound packets” were lost somewhere and only every now and then something was audible. If this happens again, I’ll focus more about capturing the nature of a problem. I did not expect yesterday, that it may not be easily reproducible.