Virtualbox package still broken on Tumbleweed

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.

There is a bug ticket with Virtualbox:
https://www.virtualbox.org/ticket/22193

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?

Regards,
Martin

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).

I used to go with the regular package in the standard repo. Once that broke as part of the 7.1 upgrade I also tried the one from
URL: https://download.opensuse.org/repositories/Virtualization/openSUSE_Tumbleweed
Same result.

I see here:

bruno@LT-B:~> rpm -qf /lib64/libdl.so.2
glibc-2.40-2.1.x86_64
bruno@LT-B:~>

Why would it return an error?

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.

Sorry, I should read more carefully. No 32 bit lib installed here, so is @smartysmart34 using a 32 bit system perhaps?

No. 64 bits

rpm -qf /lib64/libdl.so.2
xxxxxxx:~> rpm -qf /lib64/libdl.so.2
glibc-2.40-2.1.x86_64

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…)?

To me the question is why the heck a 64-package of Virtualbox only creates a /usr/lib/virtualbox directory and not a /usr/lib64/virtualbox?

KDE in my case.

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):

https://bugzilla.opensuse.org/show_bug.cgi?id=1231346#c5

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.

https://bugzilla.opensuse.org/show_bug.cgi?id=1231346#c9

I can confirm that deleting ~/.VirtualBox fix the problem. Configuration dir now is ~/.config/VirtualBox.

2 Likes

Confirming I have ~/.config/VirtualBox here (and ~/Virtualbox VMs).

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.