Starting from a clean Slackware64-current (20210320) install, and then installing VirtualBox 6.1.18, the following seems to be a common path to a segfault that keeps VirtualBox from starting...

$ virtualbox

(process:27731): GLib-GObject-WARNING **: 23:21:10.670: cannot register existing type 'NMAgentManagerError'

(process:27731): GLib-CRITICAL **: 23:21:10.670: g_once_init_leave: assertion 'result != 0' failed

(process:27731): GLib-GObject-WARNING **: 23:21:10.670: cannot retrieve class for invalid (unclassed) type '<invalid>'

Segmentation fault


Uninstalling NetworkManager, network-manager-applet, and libnma... and then starting VirtualBox seems to (temporarily) solve the problem.


I happened to later install a newer VirtualBox testbuild, because I'm trying to resolve a different Win10 VM not booting/kernel mode trap issue on the VirtualBox linux hosts forum.

I rebooted my Slackware64-current system to tweak virtualization settings off/on in my Host BIOS, and I hibernated my system last night.

After resuming my system from hibernation, and starting VirtualBox a few times around the Win10 VM troubleshooting/logging, the VirtualBox/Glib error/segfault surfaced again, and kept me from starting VirtualBox again until I did another remove/reinstall of NetworkManager/network-manager-applet/libnma.

I"m not sure if the reboots or the hibernation are responsible from the VirtualBox/Glib segfault, and I don't know if the solution is to rebuild the NetworkManager/network-manager-applet/libnma stuff, but I'm bringing this up as a recurring issue.

FYI, the related VirtualBox threads...

https://forums.virtualbox.org/viewto...p?f=7&t=102257 (VBox/Glib segfault)

and

https://forums.virtualbox.org/viewto...p?f=7&t=102269 (Win10 VM not starting w/VBox 6.1.x, kernel 5.10.25, etc...)

I also noticed that the stable release (do GNOME projects still do even/odd release numbers for stable/dev?) of NetworkManager seems to be 1.30.2, and Slackware64-current is at 1.28.0.

You should read this thread.

The solution seems to be using a test build.

https://www.virtualbox.org/wiki/Testbuilds

1 members found this post helpful.

I mentioned trying a newer test build in my first post, same issue after some mix of hibernation and/or reboots.

In any case, it seems that the 10th gen Icy Lake processor and other recent hardware and 5.8 or newer kernels are tied to deeper issues with Win10 kernel crashes in VirtualBox, based on a follow-up and link to a virtualbox trouble ticket on my latest virtualbox forums thread.

The Glib/NetworkManager segfault crash is a minor annoyance in comparison, as with many things GNOME/glib/gtk.

This happens to be on a $300 (normally $450) 15" i3 Lenovo Ideapad 3 from late 2020 Best Buy sales, and issues with shiny new hardware and bleeding-edge kernels are nothing new.

If you like you can try this build see if the errors are the same.
https://github.com/rhintze57/VirtualBox-Slackbuild

1 members found this post helpful.

See this thread: https://www.linuxquestions.org/quest...27-4175690823/

Same errors. That really fixed it.

This 'auto-update disabling' tweak for VirtualBox doesn't seem to make any difference on my system

The point of my post was to basically note that any new install or update of VirtualBox seems to lead to the same Glib/NetworkManager segfault/crash, and the only reliable (temporary) fix is to uninstall all of the NetworkManager bita (NetworkManager, network-manager-applet, and libnma), and then start VirtualBox, and then reinstall the NetworkManager bits again.

Just FYI, I'm using Xfce as a DE, in case anyone was wondering.

I do appreciate the suggestions so far, but I'll likely be waiting for a VirtualBox release that resolves issues with newer 10th/11th gen processors that currently leave me with an unusable Win10 VM, that has nothing to do with any particular linux distribution.

It worked for me, and I was getting the exact same error messages as you. If you look through the threads on it, you'll see that it also worked for a few others too.
Despite what the messages say, my understanding of the threads we've already seen about this is that the problem is more to do with the version of QT5 which ships with VB than anything else.
What happens when you try it under KDE?

Sure, I've noticed the threads about the disabling of VirtualBox auto-update being a fix.

I don't have KDE installed, and I've been excluding kde and kdei from my slackware-current reality for as long as kde/kdei have existed.

$ rsync -av --delete --exclude extra --exclude pasture --exclude patches --exclude slackware64/kde --exclude slackware64/kdei --exclude source --exclude testing $rsynchost::slackware/slackware64-current .


So, I went ahead and humored the auto-update tweak one more time, and I just realized that I had been running the tweak (as root) right after I installed the extpack at the CLI (as root).

Funny thing, the posts that mention people running VirtualBox as root make me cringe, but I was thinking that the auto-update tweak could be a global setting when run as root, as a sort of 'install the extpack, and disable auto-update globally as root' before getting back to actually using VirtualBox (as a normal user, of course).

I'm guessing you've also noticed that checking for updates manually will still crash VirtualBox (as many have mentioned), so the auto-update tweak isn't a permanent fix.

Another option would be to ditch NetworkManager, and its applet, and libnma, and go back to using 'wicd' as a network manager alternative.

Edit: looks like wicd was dropped from -current/extra, probably because the last release of wicd was in 2016.

1 members found this post helpful.

FYI, I just did the following...

Removed NetworkManager, network-manager-applet, and libnma

Built wicd from Slackware64-14.2/extra and installed wicd.

No more VirtualBox/Glib segfault crashes after a fresh VirtualBox 6.1.18 install, no auto-update disable tweak needed, and no crash on manual checks for updates.

I am still curious if -current will get a bump to the latest stable version of Network Manager (1.30.2), in case that happens to actually fix the VirtualBox/Glib/libnma crashes.

I bumped my previously (not really) 'solved' thread on the VirtualBox Linux Hosts forum, in case they're willing to do further investigation and come up with a fix for the official VirtualBox packages

Also raised as an issue with NetworkManager developers, although I'm not sure it'll be feasible to investigate all of the moving parts to find the real problem...

https://gitlab.freedesktop.org/Netwo...r/-/issues/693

I use VBox : Version 6.1.19 r142995
with : Oracle_VM_VirtualBox_Extension_Pack-6.1.19-142994

Without any issue on slackware-current, NetworkManager 1.28, kernel 5.11.10