[20.04] Workaround for Xorg crashes to Login prompt in Virtual Machines

Currently there is a bug in 20.04 that causes the desktop xorg session to crash and drop the user back to the GUI Login screen.

This bug occurs with several programs and is not limited to Ubuntu MATE. However, it is particularly troublesome for us as Welcome is one of the programs that this issue affects. It is possible for a user running Ubuntu MATE 20.04 in a Virtual Machine to come upon a login-crash loop.

While this is being worked out, there are a couple of workarounds.

  1. On the first boot after installation, before logging into the machine, drop into a TTY session login and remove the gstreamer-vaapi application. Then the user can login to the machine and not have the possibility of this particular login crash loop.

    At the GUI Login screen:

    1. Ctrl + Alt + F1 to enter a TTY.

    2. Login with your username and password and do the following:

      sudo apt-get purge gstreamer1.0-vaapi
      sudo apt-get autoremove --purge
      
    3. Ctrl + Alt + F7 will bring you back to the GUI Login and you can proceed as you would normally.

  2. If using KVM or QEMU Virtual Machines please use 'virtio' as your video adapter
    If using Virtual Box please use VMVGA as your video adapter.

9 Likes

I installed Ubuntu Mate 20.04.1 on my SSD a couple of days ago and every time I boot up I get a black screen with the mouse cursor. Only way to show the desktop is by CTRL + ALT to a TTY and changing back to the desktop with Ctrl + Alt + F7. That fixes it.

Is mine related to this one or is it different?

What is the nature of gstreamer? Does it call Xorg in a way that causes the crash? How much will I miss it when it is gone?

Thank you.

GStreamer is a library which handles audio and video processing. It's usually used by GNOME applications and their derivatives for multimedia decoding and encoding, usually the former to display / play video and audio files.

WebKit, an HTML "rendering engine" (core of a Web browser), is among the users of GStreamer; multimedia files abound on the modern Web, and thus WebKit needs to support multimedia files in order to be competitive in the modern Web rendering engine arena. This last point matters because the Ubuntu MATE Welcome application (and even the Software Boutique, I think [!]) uses WebKit to display the fancy user interface of the Welcome application. (Why WebKit is used for the purpose remains a mystery to me. My best guess is that the designer of the Welcome application wasn't so comfortable writing a conventional program and adding all kinds of special effects and animations to the program code, and so decided to write the application mostly in HTML.)

GStreamer is highly modular; by itself, GStreamer can't do very much of use. You therefore need to add plugins to GStreamer to extend its functionality, to play MP3s, for instance, or use special hardware features to decode and encode multimedia at super speeds.

The latter describes the VA-API plugin that you've been directed to remove; all that you'd remove is the ability for GStreamer to use special features of modern hardware (usually graphics cards) to turn audio and video encoding / decoding from a somewhat slow speed into a quick, real-time process that uses relatively little electricity. You would not remove the entirety of GStreamer by removing this gstreamer1.0-vaapi package; if you did remove the entirety of GStreamer, you'd probably remove half your desktop applications. (GStreamer is needed by WebKit; as well as being needed by the Welcome app, WebKit is needed by Zenity, which is used by the MATE window manager Marco. Many other intricate tangles of proverbial cyber threads attach GStreamer to dozens of other applications, and all in all, you'd have a very crippled desktop.) Fortunately, this workaround does not involve uninstalling all of GStreamer.

Now you're probably saying, "Less electricity use? Isn't this a pretty important package then?" But the fact is that really only computer systems from the last 6 or 7 years have this special hardware required for VA-API support. Furthermore, if you're running Ubuntu MATE inside a virtual machine, chances are your virtual machine lacks any such (virtualized or real) en/decoding hardware! Unless you actually have a system which can truly support VA-API, removing the package will not cause any harm.

As for why this plugin interats with X.org so bad: I looked at the pertinent bug reports, and it's fairly clear to me that nobody really knows why this VA-API plugin for GStreamer crashes X sometimes. Some say it's a bug in the VA-API driver itself; others note that it must be a bug in X since the problem occasionally still persists even after the package is removed.

My personal opinion, as a guy who really doesn't know what he's talking about in this exact regard, is that on some hardware configurations, the same hardware circuits in charge of hardware multimedia en/decoding are the same as the ones used by graphics acceleration (for displaying stuff on-screen really fast, as opposed to simply decoding video really fast, leaving the actual display process up to another component of the system). Or it could be that it's not the hardware at fault, but the software: I've noticed that under a lot of circumstances, the driver for VA-API comes from the Mesa project, which is primarily focused on hardware-accelerated graphics rendering. Maybe, just maybe, some of the drivers for VA-API on certain hardware somehow conflict with the drivers for graphics acceleration.

But that's just a W.A.G on my part, and I really have no business preaching stuff that's outside my field of expertise. So I'll leave facts at facts and move on. Still, I hope my diatribe was at least half-useful for clarification purposes.

2 Likes

Doggie, that was first-class, private plane treatment! Thank you. My approach will be to remove it as you suggest and see what happens. :flushed:

I am slightly familiar with vaapi in association with video transcoding. It's pretty relevant to our gizmo. Think of it as a local media server. (http://www.button.network) I took a run at doing video transcoding with hardware assist (through FFMPEG). After four or five days, I decide that if I ever got it working, it would be brittle and failure prone. We just do it in software.

You mentioned Marco, the other thing that has been crashing. (Three days up on Mate and we have two subsystems crashing frequently. :roll_eyes:) I wonder if there is any shot that the root cause is the same for both . . .

FWIW, we are running Raspberry Pi ARM64 with 20.04.2. We are just moving to Mate because KDE is not well-supported on the Pi AFAIK.

Thanks again for the great background.

1 Like

Joke's on me. I don't have gstreamer1.0-vaapi installed.

Reading package lists... Done
Building dependency tree       
Reading state information... Done
Package 'gstreamer1.0-vaapi' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 14 not upgraded.

I did not look for any other similar modules (like a different version), but I could.

So, our little Pi is subject to rapid-fire crashes from both Xorg and Marco. They seem unrelated. The crash files, for example show different labeling and permissions. Excerped Xorg log file below. (I removed some of the proc maps and the core dump.)

-rw-r----- 1 service whoopsie 2705871 Aug 15 00:50 _usr_bin_marco.1000.crash
-rw-r----- 1 root    whoopsie 2554675 Aug 16 14:12 _usr_lib_xorg_Xorg.0.crash        <-- this one
  
  
Architecture: arm64
Date: Mon Aug 16 14:12:52 2021
DistroRelease: Ubuntu 20.04
ExecutablePath: /usr/lib/xorg/Xorg
ExecutableTimestamp: 1625566671
ProcCmdline: /usr/lib/xorg/Xorg -core :1 -seat seat0 -auth /var/run/lightdm/root/:1 -nolisten tcp vt8 -novtswitch
ProcCwd: /
ProcEnviron: PATH=(custom, no user)
ProcMaps:
 aaaadc82f000-aaaadca76000 r-xp 00000000 b3:02 89303                      /usr/lib/xorg/Xorg
 aaaadca86000-aaaadca8b000 r--p 00247000 b3:02 89303                      /usr/lib/xorg/Xorg
 aaaadca8b000-aaaadca96000 rw-p 0024c000 b3:02 89303                      /usr/lib/xorg/Xorg
 aaaadca96000-aaaadcad4000 rw-p 00000000 00:00 0 
 aaaae3ad0000-aaaae3f6d000 rw-p 00000000 00:00 0                          [heap]
 ffff6c000000-ffff6c021000 rw-p 00000000 00:00 0 
 ffff6c021000-ffff70000000 ---p 00000000 00:00 0 
 ffff74000000-ffff74021000 rw-p 00000000 00:00 0 
 ffff74021000-ffff78000000 ---p 00000000 00:00 0 
 ffff78000000-ffff78021000 rw-p 00000000 00:00 0 
 ffff78021000-ffff7c000000 ---p 00000000 00:00 0 
 ffff7c000000-ffff7c021000 rw-p 00000000 00:00 0 
 ffff7c021000-ffff80000000 ---p 00000000 00:00 0 
 ffff80000000-ffff80021000 rw-p 00000000 00:00 0 
 ffff80021000-ffff84000000 ---p 00000000 00:00 0 
 ffff86504000-ffff86584000 rw-s 101f3b000 00:06 941                       /dev/dri/renderD128
 ffff86584000-ffff865cf000 rw-p 00000000 00:00 0 
 ffff865cf000-ffff865d4000 r-xp 00000000 b3:02 16958                      /usr/lib/aarch64-linux-gnu/libxcb-sync.so.1.0.0
 ffff865d4000-ffff865e4000 ---p 00005000 b3:02 16958                      /usr/lib/aarch64-linux-gnu/libxcb-sync.so.1.0.0
 ffff865e4000-ffff865e5000 r--p 00005000 b3:02 16958                      /usr/lib/aarch64-linux-gnu/libxcb-sync.so.1.0.0
 ffff865e5000-ffff865e6000 rw-p 00006000 b3:02 16958                      /usr/lib/aarch64-linux-gnu/libxcb-sync.so.1.0.0
 ffff865e6000-ffff865e8000 r-xp 00000000 b3:02 16952                      /usr/lib/aarch64-linux-gnu/libxcb-present.so.0.0.0
 ffff865e8000-ffff865f7000 ---p 00002000 b3:02 16952                      /usr/lib/aarch64-linux-gnu/libxcb-present.so.0.0.0
 ffff865f7000-ffff865f8000 r--p 00001000 b3:02 16952                      /usr/lib/aarch64-linux-gnu/libxcb-present.so.0.0.0
 ffff865f8000-ffff865f9000 rw-p 00002000 b3:02 16952                      /usr/lib/aarch64-linux-gnu/libxcb-present.so.0.0.0
 ffff865f9000-ffff865fc000 r-xp 00000000 b3:02 16940                      /usr/lib/aarch64-linux-gnu/libxcb-dri3.so.0.0.0
 ffff865fc000-ffff8660b000 ---p 00003000 b3:02 16940                      /usr/lib/aarch64-linux-gnu/libxcb-dri3.so.0.0.0
 ffff8660b000-ffff8660c000 r--p 00002000 b3:02 16940                      /usr/lib/aarch64-linux-gnu/libxcb-dri3.so.0.0.0
 ffff8660c000-ffff8660d000 rw-p 00003000 b3:02 16940                      /usr/lib/aarch64-linux-gnu/libxcb-dri3.so.0.0.0
 ffff8660d000-ffff8661a000 r-xp 00000000 b3:02 7592                       /usr/lib/aarch64-linux-gnu/libwayland-client.so.0.3.0
 ffff8661a000-ffff86629000 ---p 0000d000 b3:02 7592                       /usr/lib/aarch64-linux-gnu/libwayland-client.so.0.3.0
 ffff86629000-ffff8662b000 r--p 0000c000 b3:02 7592                       /usr/lib/aarch64-linux-gnu/libwayland-client.so.0.3.0
  
                              < . . . and much more . . . >
  
 ffffb0c9d000-ffffb0cac000 ---p 00025000 b3:02 3241                       /usr/lib/aarch64-linux-gnu/libselinux.so.1
 ffffb0cac000-ffffb0cad000 r--p 00024000 b3:02 3241                       /usr/lib/aarch64-linux-gnu/libselinux.so.1
 ffffb0cad000-ffffb0cae000 rw-p 00025000 b3:02 3241                       /usr/lib/aarch64-linux-gnu/libselinux.so.1
 ffffb0cae000-ffffb0cb0000 rw-p 00000000 00:00 0 
 ffffb0cb0000-ffffb0cd8000 r-xp 00000000 b3:02 20732                      /usr/lib/aarch64-linux-gnu/libudev.so.1.6.17
 ffffb0cd8000-ffffb0ce8000 ---p 00028000 b3:02 20732                      /usr/lib/aarch64-linux-gnu/libudev.so.1.6.17
 ffffb0ce8000-ffffb0ce9000 r--p 00028000 b3:02 20732                      /usr/lib/aarch64-linux-gnu/libudev.so.1.6.17
 ffffb0ce9000-ffffb0cea000 rw-p 00029000 b3:02 20732                      /usr/lib/aarch64-linux-gnu/libudev.so.1.6.17
 ffffb0cea000-ffffb0d37000 r-xp 00000000 b3:02 2905                       /usr/lib/aarch64-linux-gnu/libdbus-1.so.3.19.11
 ffffb0d37000-ffffb0d47000 ---p 0004d000 b3:02 2905                       /usr/lib/aarch64-linux-gnu/libdbus-1.so.3.19.11
 ffffb0d47000-ffffb0d48000 r--p 0004d000 b3:02 2905                       /usr/lib/aarch64-linux-gnu/libdbus-1.so.3.19.11
 ffffb0d48000-ffffb0d49000 rw-p 0004e000 b3:02 2905                       /usr/lib/aarch64-linux-gnu/libdbus-1.so.3.19.11
 ffffb0d4a000-ffffb0d4b000 rw-p 00000000 00:00 0 
 ffffb0d4b000-ffffb0d4c000 rw-s 1008a0000 00:06 941                       /dev/dri/renderD128
 ffffb0d4c000-ffffb0d5b000 rw-p 00000000 00:00 0 
 ffffb0d5b000-ffffb0d7c000 r-xp 00000000 b3:02 2818                       /usr/lib/aarch64-linux-gnu/ld-2.31.so
 ffffb0d7c000-ffffb0d8a000 rw-p 00000000 00:00 0 
 ffffb0d8a000-ffffb0d8b000 r--p 00000000 00:00 0                          [vvar]
 ffffb0d8b000-ffffb0d8c000 r-xp 00000000 00:00 0                          [vdso]
 ffffb0d8c000-ffffb0d8d000 r--p 00021000 b3:02 2818                       /usr/lib/aarch64-linux-gnu/ld-2.31.so
 fffff543a000-fffff545b000 rw-p 00000000 00:00 0                          [stack]
ProcStatus:
 Name:	Xorg
 Umask:	0022
 State:	S (sleeping)
 Tgid:	4612
 Ngid:	0
 Pid:	4612
 PPid:	2031
 TracerPid:	0
 Uid:	0	0	0	0
 Gid:	0	0	0	0
 FDSize:	64
 Groups:	 
 NStgid:	4612
 NSpid:	4612
 NSpgid:	4612
 NSsid:	4612
 VmPeak:	 1089864 kB
 VmSize:	 1031924 kB
 VmLck:	       0 kB
 VmPin:	       0 kB
 VmHWM:	   54712 kB
 VmRSS:	   54712 kB
 RssAnon:	   17932 kB
 RssFile:	   36776 kB
 RssShmem:	       4 kB
 VmData:	  114628 kB
 VmStk:	     132 kB
 VmExe:	    2332 kB
 VmLib:	  112792 kB
 VmPTE:	     404 kB
 VmSwap:	       0 kB
 CoreDumping:	1
 THP_enabled:	0
 Threads:	13
 SigQ:	1/14018
 SigPnd:	0000000000000000
 ShdPnd:	0000000000000000
 SigBlk:	000000000a392000
 SigIgn:	0000000000001000
 CapInh:	0000000000000000
 CapPrm:	0000003fffffffff
 CapEff:	0000003fffffffff
 CapBnd:	0000003fffffffff
 CapAmb:	0000000000000000
 NoNewPrivs:	0
 Seccomp:	0
 Speculation_Store_Bypass:	unknown
 Cpus_allowed:	f
 Cpus_allowed_list:	0-3
 Mems_allowed:	1
 Mems_allowed_list:	0
 voluntary_ctxt_switches:	3797
 nonvoluntary_ctxt_switches:	113
Signal: 6
Uname: Linux 5.4.0-1041-raspi aarch64
UserGroups: N/A
CoreDump: base64
 H4sICAAAAAAC/0NvcmVEdW1wAA==

I made a mistake yesterday (or something changed). My new story - repeatedly confirmed this morning - is that Xorg is crashing every time I perform a logout or switch user. I seem to have lost the formula for producing Marco crashes but I can consistently generate Xorg crashes.

In light of that, I posted a completed crash file, including core dump here: http://www.button.network/_usr_lib_xorg_Xorg.0.211018a.txt