In a fully updated ~amd64 system I'm seeing exactly the problem described in https://bbs.archlinux.org/viewtopic.php?id=299392. These users also created a virtualbox ticket for it: https://www.virtualbox.org/ticket/22193 The symptom is that a Signal 11 is received during early VM startup and the virtualbox UI shows the (generic) error 0x80004005. The solution is: ln -s /usr/lib64/libdl.so.2 /usr/lib64/virtualbox/libdl.so ln -s /usr/lib64/libpthread.so.0 /usr/lib64/virtualbox/libpthread.so Reproducible: Always
Same problem here with virtualbox-7.1.4, same solution: ln -s /lib64/libpthread.so.0 /usr/lib64/virtualbox/libpthread.so ln -s /lib64/libdl.so.2 /usr/lib64/virtualbox/libdl.so BTW this seems to be the same as https://bugs.gentoo.org/939878 According to https://stackoverflow.com/questions/75855053/how-to-address-crash-due-to-missing-libdl-so-on-ubuntu-22#75855054, the error lies with the build process that links the binary to libdl.so and libpthread.so instead of their versioned names libdl.so.2 and libpthread.so.0. As long as libdl.so libpthread.so are still available somewhere in the ldpath when the binary is run, the problem will not occur. But it seems this is by no means guaranteed. I would set the status of this ticket to confirmed.
I have exactly the same thing (I even posted a thread on this in the forums https://forums.gentoo.org/viewtopic-t-1172803.html) and now I wanted to make a bug report of this. All my VMs end up with the NS_ERROR_FAILURE (0x80004005) error and on dmesg and can see [ 4893.378288] VirtualBoxVM[21455]: segfault at 0 ip 00007f902df3665d sp 00007ffc13e56548 error 4 in libc.so.6[7f902de66000+f5000] likely on CPU 12 (core 4, socket 0) [ 4893.378302] Code: 00 00 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 89 f8 48 89 fa c5 f9 ef c0 25 ff 0f 00 00 3d e0 0f 00 00 0f 87 33 01 00 00 <c5> fd 74 0f c5 fd d7 c1 85 c0 74 57 f3 0f bc c0 c5 f8 77 c3 66 66 In my logs I also noticed the "Failed to open /dev/vboxdrvu" error message. However, making /dev/vboxdrvu writeable and readable for the vboxusers group did not help at all. The error message was gone, but the NS_ERROR_FAILURE (0x80004005) remained. I ended up masking virtualbox-7.1.4 and downgrading to 7.0.22 and my VMs immediately run again. The only thing that is still strange is that after the downgrade (of course I did modprobe -r vbox.... before the downgrade and modprobe vbox... after the downgrade) is that /dev/vboxdrvu is still only readable for root only. But my VM start and work without a problem though.
Did you try the `ln -s` solution? Does it work?
(In reply to Viorel Munteanu from comment #3) > Did you try the `ln -s` solution? Does it work? Not yet. Because I was in a hurry and needed to boot into one of my VMs, I just downgraded first. Later in the evening I started reading the different threads and that's where I've stumbled across the symlink solution. I will try it in the evening though.
I have the similar error message in journal (error in VBoxDDR0.r0 rather than in libc): Feb 02 10:26:52 localhost kernel: vboxdrv: 00000000f4a41f7b VMMR0.r0 Feb 02 10:26:52 localhost kernel: vboxdrv: 00000000b0a280c1 VBoxDDR0.r0 Feb 02 10:26:53 localhost kernel: EMT-0[279251]: segfault at 7f205ce49000 ip 00007f205e089770 sp 00007f208aafaa30 error 6 in VBoxDD.so[e4770,7f205dfaf000+251000] likely on CPU 8 (core 2, soc> Feb 02 10:26:53 localhost kernel: Code: c8 31 c0 80 bf 2a 0d 01 00 00 c7 45 c0 00 00 00 00 62 f1 7f 28 7f 45 fd 75 40 31 db 49 89 f5 4c 8d 75 9c c5 f8 77 eb 0d 66 90 <41> 89 84 9c 88 11 01 0> Feb 02 10:26:53 localhost systemd-coredump[279310]: Process 279222 (VirtualBoxVM) of user 1000 terminated abnormally with signal 11/SEGV, processing... Feb 02 10:26:53 localhost systemd-coredump[279311]: [🡕] Process 279222 (VirtualBoxVM) of user 1000 dumped core. but the ln-s solution does NOT work for me. Other user in referenced archlinux thread mentioned error on another lib (UICommon.so), so the lib name may not be the root cause.
*** Bug 949801 has been marked as a duplicate of this bug. ***
