Hello all,
ever since Tumbleweed started shipping VirtualBox 7.1 I can nots tart VMs anymore. When trying to strart a VM, I receive the folowing error:
The virtual machine ‘OpenSuse Tumbleweed Para’ has terminated unexpectedly during startup because of signal 11.
Hello Larryr,
I am not trying to start a saved state. I am using Snapshots in one case though. So I have one VM with a snapshot, the other without. Both fail on startup, I don’t even get to see their VMs window come up. It immediately fails.
My host has Secure boot off at the moment. Starting the VMs still fails.
Hi, 7.1.4 works here, but I had a Guest that refused to load and I had to change the guest Network setting to fix it.
There are apparently some problems with NAT networking, something changed in recent versions, so try disabling Network or start with Bridged.
Then if a guest starts, you may be able to set a working NAT config if you need it.
Hm. So - yes - I do NOT have Slowroll installed. Just regular Tumbleweed as was fit throughout the last couple of years. Are you saying in order to use VBox 7.1 I need to switch to Slowroll? Is this a permanent thing? Or just temporarily? If so: For how long is this estimated to be required?
Kind regards,
Martin
No Slowroll has different kernel and needs different virtualbox build.
If you started with Tumbleweed and switched to Slowroll - zypper will install the wrong versions. You fix that by installing longterm kernel in Slowroll. That gets things back in sync.
do you have the extension packs installed. They really are not needed in 7.x Virtualbox as the primary reason is built into 7.x - I would uninstall it from the GUI.
You only need if for special networking (guest to guest only).
Hello all.
I had another look today. When I try to start a VM the following appears in the syslog (dmesg):
[ T10472] VirtualBoxVM[10472]: segfault at 0 ip 00007fd3a717b66d sp 00007ffcfee293c8 error 4 in libc.so.6[17b66d,7fd3a7095000+10d000] likely on CPU 2 (core 2, socket 0)
So it seems to be an issue between VBox and libc.
I fail to understand how this can only be affecting me? All my Tumbleweed packages are updated to the latest versions… Shouldn’t this be similar to a couple thousend other PCs as well?
Googling for the segfault / libc issue brings me to this Arch thread again: https://bbs.archlinux.org/viewtopic.php?id=299392
And here we are with the two missing links I mentioned in the beginning.
But the directory they are referring to does not exist in my suse installation:
/usr/lib/virtualbox/
ls -l /usr/src/linux /usr/src/linux-obj/x86_64/default
should reference only the 6.11.5-1 kernel.
And zypper lu -a shouldn’t list any missing or blocked updates.
Next try rebuilding the kernel modules.
zypper in --force virtualbox-kmp-default
dracut --kver=6.11.5-1-default --force
The explicit dracut may be redundant and I agree that it should be redundant. However when I recently did this with the nvidia kmp, I found that even though dracut was invoked automatically not just once but twice as part of the reinstall, it didn’t actually touch the ramdisk images at all, which was very surprising. (snapper status showed that the images hadn’t changed.) This may just be an nvidia kmp oddity.
The other thing I’m wondering about is if this might have something to do with Oracle’s proprietary extensions pack?
This one surprisingly shows quite some packages which have updates. They are from either Packman (Discord, dvgrab, libvulcan?!?, Mesa ?!?) - How the heck did the last two end up from Packman?!? - or from Graphics /Pdftk-gui.
Surprisingly enough, even though both the repos are active / enabled, a ‘zypper dup’ does not pick these up…
UPDATE: This was a bit misleading: mesa and libvulcan were shown as “Packman has an update”, but when checking in Yast they are actually installed from Opensuse. It is just that in the other repository (Packman) there is a newer version which is not picked up because I do not switch over to that repository…
This is probably a side quest but what’s the output from
zypper lr -Pd
The -a option shows all upgrades that are available with a vendor change or by ignoring locks. Normally when people use the full packman repo, they do want to switch things like Mesa or vulkan stuff over to Packman, with --allow-vendor-change. It would also show upgrades for packages that are currently locked which is why I wanted to see it. Unrelated to your problem: If you want to limit Packman usage, maybe packman-essentials would make sense.
Segmentation faults can be caused in many different ways (and programmers are finding new ones every day), but a linking issue is indeed one possibility. And almost everything uses glibc, including the kmp. It could also be that something is involved that most people don’t use like a plugin because as you noted this appears to be a rare problem. (I created a couple of vms and everything works fine over here, sorry works for me is of course not a helpful response.)
Do rebuild the kmp. As for glibc, that’s one of the basic building blocks of most Linux systems so kind of important. For example, if there was something obvious wrong with libc, the system probably wouldn’t even be able to boot.
So those would be the expected locations for libc.so* and their respective packages, all from the openSUSE-Tumbleweed-Oss repo. You could use say zypper if glibc glibc-devel to check although it would be very surprising if they were different.