Hello all.
As mentioned in a previous post in autumn, ever since Virtualbox 7.1 was introduced to Tumbleweed VMs would not start but receive signal 11.
Finally going with the comment from Nov. 13th (in the ticket) resolved it for me:
ln -s /lib64/libpthread.so.0 /usr/lib/virtualbox/libpthread.so
ln -s /lib64/libdl.so.2 /usr/lib/virtualbox/libdl.so
I am thinking: Shouldn’t that symlink be shipped with the Suse package for the time being?
How did you install VB 7.1? Here on TW VB 7.1.4 from the openSUSE OSS repo is installed and working, those /lib64/lib* files are there and there is no lib* in /usr/lib/virtualbox/ so the “fix” you suggest would return an error?
No problems here with the openSUSE provided package as OrsoBruno mentioned. I use VB nearly daily to test different stuff. Neither old VMs nor fresh VMs have any issue (different Linux guest distros).
So there seems to be more involved to reproduce such issue.
The other question is if it would work for the affected ppl, to simply install glibc-32bit as this package provides the libraries (32 bit lib).
Yes, but the provided „fix“ from the VB forum creates a symbolic link from the 64bit library (lib64) to a 32bit path (lib). So thats why i asked if installation of glibc-32bit might help the affected ppl. That would be at least a clean way instead of random linking.
OK, standing by since I cannot reproduce. This system was installed years ago and dup’ed regularly. Maybe uninstalling VB and installing other versions changed something for the OP?
Using Gnome here, maybe other DEs need a 32 bit link (just a shot in the dark, but @hui is using KDE…)?
That is the path, the virtualbox package is providing, even if you install the 64bit version of Virtualbox. See also YAST File-List of the installed package…
You are still circling around my question: does installation of glibc-32bit help (after you removed the symbolic links) in your case? Because on my machines glibc-32bit is installed (it’s a dependency for the Nvidia drivers) and i don’t need any symbolic links to get VB to work.
If this is the case, this would be a proper fix and would help in case someone would open a bugreport.
It is not a glibc issue. A short search revealed the real fix which is explained in this bugreport. The config directory in home changed (so only VB versions which were upgraded from really old versions seems affected):
After some more trying I removed the virtualbox config dir in home and started virtualbox and so creating a fresh configuration, and after importing all existing vm’s everything works as expected without the need to have the symlinks to the libraries.