Bug 1780888 - VirtualBox crashes on Fedora 31 with default Gnome setup
Summary: VirtualBox crashes on Fedora 31 with default Gnome setup
Keywords:
Status: CLOSED DUPLICATE of bug 1758724
Alias: None
Product: Fedora
Classification: Fedora
Component: qt5-qtwayland
Version: 31
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-12-08 08:27 UTC by Nadav Har'El
Modified: 2019-12-09 17:20 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-12-09 07:49:33 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Nadav Har'El 2019-12-08 08:27:45 UTC
I know that VirtualBox isn't one of Fedora's official packages, but it's still very popular and supplied by RPM Fusion, so it would be a shame if it stopped working - which it did on Fedora 31.

VirtualBox has been working well on previous Fedora releases, but starting with Fedora 31, it immediately crashes when running "virtualbox", before showing its normal UI; On "dmesg" there appear some messages suggesting that the crash happened inside the Qt library (unfortunately I don't have these messages handy right now).

Searching on the Web, I found someone suggesting that this is a Wayland-specific bug in Qt, and that removing the "qt5-qtwayland" package (that apparently nothing depends on?) should fix the crash - and sure enough, it did - and with this library uninstalled, virtualbox is back to working.

I also noticed that although these crashes were apparently happening on the default Wayland-based Gnome desktop, if I ran an X-Window based user with xinitrc, this problem doesn't happen despite qt5-qtwayland being install (I'm guessing it's simply not used in this case).

Comment 1 Jan Grulich 2019-12-09 07:49:33 UTC
This is because starting Fedora 31 we use Wayland backend by default and Virtualbox unfortunately doesn't work with it. You will need to open a bug for RPM fusion package and tell them to force "xcb" plugin for Virtualbox instead.

Comment 2 Nadav Har'El 2019-12-09 08:43:44 UTC
Ok, thanks. I wonder if this decision to "use the Wayland backend by default" wasn't premature, given that some of the most popular out-of-distro software can't work with it yet (and to be honest, I have no idea *why* it doesn't work).
I see rpmfusion already have an issue about this: https://bugzilla.rpmfusion.org/show_bug.cgi?id=5383

Comment 3 Jan Grulich 2019-12-09 08:46:54 UTC
This is not fault of Wayland, but fault of the software depending on X11 stuff and I believe that most of this software will not work for a while as they will need major changes. This shouldn't really block usage of Wayland.

Comment 4 Nadav Har'El 2019-12-09 09:07:39 UTC
It's easy to say "it's not the fault of Wayland", but this isn't just VirtualBox, the RPM-fusion bug tracker that multiple applications with exactly the same problem. Also smplayer and mixxx. This was also reported in https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/thread/XTR7O3X2OSDBXRJBILL7B7NBAX3564EQ/.

The text in https://fedoraproject.org/wiki/Changes/Qt_Wayland_By_Default_On_Gnome, which explains what change caused all these problems, contains hints of these problems: It describes the Wayland plugin "becoming more and more reliable" but not that it's already reliable. It also strange patches that were apparently needed to be done to get this to actually work on a Gnome desktop - which is, after all, Fedora's default desktop.

Apparently these tweaks aren't as good as was previously thought, and a lot of out-of-distro applications don't work with them. I wonder whether the problems all these applications are facing can't be fixed by fixing the qt5-qtwayland plugin somehow - or, unfortunately, roll back the decision to make it the default (I simply uninstalled the qt5-qtwayland package, and nothing bad seemed to happen).

It's sad that these bugs are already known for 3 months, and did not get fixed by none of Fedora, RPMfusion, or the end-application (like VirtualBox or Smplayer). Users (like me) are discovering them the hard way - when upgrading to Fedora 31 and things suddenly stop working.

Comment 5 Nadav Har'El 2019-12-09 09:09:40 UTC

*** This bug has been marked as a duplicate of bug 1758724 ***

Comment 6 Jan Grulich 2019-12-09 09:40:22 UTC
(In reply to Nadav Har'El from comment #4)
> It's easy to say "it's not the fault of Wayland", but this isn't just
> VirtualBox, the RPM-fusion bug tracker that multiple applications with
> exactly the same problem. Also smplayer and mixxx. This was also reported in
> https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/
> thread/XTR7O3X2OSDBXRJBILL7B7NBAX3564EQ/.
> 
> The text in
> https://fedoraproject.org/wiki/Changes/Qt_Wayland_By_Default_On_Gnome, which
> explains what change caused all these problems, contains hints of these
> problems: It describes the Wayland plugin "becoming more and more reliable"
> but not that it's already reliable. It also strange patches that were
> apparently needed to be done to get this to actually work on a Gnome desktop
> - which is, after all, Fedora's default desktop.
> 
> Apparently these tweaks aren't as good as was previously thought, and a lot
> of out-of-distro applications don't work with them. I wonder whether the
> problems all these applications are facing can't be fixed by fixing the
> qt5-qtwayland plugin somehow - or, unfortunately, roll back the decision to
> make it the default (I simply uninstalled the qt5-qtwayland package, and
> nothing bad seemed to happen).
> 
> It's sad that these bugs are already known for 3 months, and did not get
> fixed by none of Fedora, RPMfusion, or the end-application (like VirtualBox
> or Smplayer). Users (like me) are discovering them the hard way - when
> upgrading to Fedora 31 and things suddenly stop working.

The problem with these application is that they depend on X11 API, making them to misbehave on Wayland or not to work at all. And this is not only in Gnome, but also in Plasma or any other desktop running on Wayland. 

I don't know what "strange patches" you have in mind, because I'm not aware of any. The only patch we needed was to make Wayland run by default on Gnome, it was already used by default on the other desktops.


Note You need to log in before you can comment on or make changes to this bug.