"low-graphics mode" in VirtualBox guest, but X server running

[Michael Thayer]

I sometimes get the "low-graphics mode" message when starting an Ubuntu 16.04 virtual machine inside of VirtualBox (current development code trunk, somewhere past version 5.1 beta 3 and a debug build). When I switch to VT-7 I find the X server running without any visible issues (I am the upstream developer of the guest graphics drivers, so I have a reasonable but not infallible understanding of the X server).

The virtual machine has Guest Additions installed, same vintage and also a debug build. Two screens are enabled as is 3D acceleration. The host system is also Ubuntu 16.04. I am still trying to work out what triggers the message, but in my last attempts a cold boot failed to produce it, while a clean reboot did, but only when the host system was not under load (under load as in building VirtualBox).

Searching the lightdm log files led me to the message "CRITICAL **: session_get_login1_session_id: assertion 'session != NULL' failed", which in turn led me to this similar-looking Debian bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814760

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: lightdm 1.18.1-0ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-28.47-generic 4.4.13
Uname: Linux 4.4.0-28-generic x86_64
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
CurrentDesktop: Unity
Date: Thu Jul 7 10:49:27 2016
InstallationDate: Installed on 2016-06-08 (28 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
SourcePackage: lightdm
UpgradeStatus: No upgrade log present (probably fresh install)

IRC discussion at:

  https://irclogs.ubuntu.com/2016/07/07/%23ubuntu-devel.html#t07:52

[Michael Thayer (michael-thayer)]

Just checked, I do not have that message in the current log file, attached the file from yesterday containing the message.

I asked about this on #ubuntu-devel, here are the relevant logs:

(17:09:06) michael-vb: Afternoon. Not sure if this is the right place to ask, but someone will probably know what is.
(17:09:06) michael-vb: I have the following problem with my VirtualBox Ubuntu 16.04 guest with development Guest Additions installed: when I start the guest I get the message "The system is running in low-graphics mode" (on VT 2) even though the X server is running fine (on VT 7).
(17:09:06) michael-vb: I would very much like to know exactly what logic triggers that message so I can work out why I am triggering it and change whatever is responsible (I am the developer of the VirtualBox guest driver and Additions installer).

(18:04:34) michael-vb: Interesting - I just booted the guest system twice with a loaded host (rebuilding VirtualBox) and did not get the "low-graphics mode" message.

(18:27:01) michael-vb: CRITICAL: session_get_login1_session_id: assertion 'session != NULL' failed in the lightdm log file.

(18:31:13) michael-vb: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814760

(09:57:21) sladen: michael-vb: http://askubuntu.com/questions/141606/how-to-fix-the-system-is-running-in-low-graphics-mode-error
(09:57:35) michael-vb: Found that already.

(09:57:50) michael-vb: I am wanting to understand this as a developer, not as a user.

(09:59:07) michael-vb: sladen: it was following from that askubuntu question that I found the system log entry.
(09:59:34) michael-vb: The session clearly gets started just after lightdm checks whether it is running.
(10:01:04) michael-vb: As I said, this does not happen under high load. I suppose the question is, who would understand this stuff well enough to tell me how I can avoid triggering it.
(10:01:15) michael-vb: Or what causes the session to start too late, or lightdm too early.
(10:03:00) michael-vb: I assume that some dependency is not specified well enough somewhere.
(10:03:31) sladen: michael-vb: apt-get source lightdm && grep -r "Error message" is probably the most effective way of identifing the logic causing the error (if it is coming from lightdm)
(10:03:31) michael-vb: But it is annoying, because if it hits users they will blame us first, not you!

(10:04:15) sladen: michael-vb: I'm not too familiar with the inner workings of lightdm; the developer was Robert Ancell in the DX team
(10:04:57) sladen: michael-vb: if it's happening so of the time (seemingly randomly), then there's probably a race condition
(10:06:33) michael-vb: I'm sort of suspecting that it is related to the change to systemd which upset some expectation in lightdm.
(10:08:13) sladen: willcooke: if you're around later, could you get in contact with michael-vb (upstream developer of VirtualBox guest driver), about debugging and resolving the "The system is running in low-graphics mode" message. https://irclogs.ubuntu.com/2016/07/07/%23ubuntu-devel.html#t07:52 onwards
(10:08:50) michael-vb: willcooke: and michael dot thayer at oracle if I am not on IRC at that time.
(10:08:56) michael-vb: sladen, willcooke: thank...

[Michael Thayer (michael-thayer)]

Actually, perhaps I misunderstand the lightdm log rotation and the .1 logfile does contain the relevant log. I assume the lightdm developers will know.

My uneducated guess is that there is some sort of race here between lightdm and logind which needs better dependency specification.

And I just checked that I do not always see this on a clean reboot either.

[Will Cooke (willcooke)]

Added to Trello: https://trello.com/c/Un8N5Pfs/16-bug-1599775-low-graphics-mode-in-virtualbox-guest-but-x-server-running

[Flames_in_Paradise (ellisistfroh-deactivatedaccount)]

Various bugfixes were implemented in LightDM V. 1.18.2-0ubuntu1 [1]

This package is still awaiting approval as it covers a few issues...

The bugs are referenced there. Hope this helps.

[1] https://launchpad.net/ubuntu/+source/lightdm/1.18.2-0ubuntu1

found via Pending Ubuntu SRU's: http://people.canonical.com/~ubuntu-archive/pending-sru

[Michael Thayer (michael-thayer)]

I was able to reproduce this with the lightdm deb file from that package installed. I did not install the other deb files built from the package.

[Paul Sladen (sladen)]

@ellisistfroh: I cannot see anything in the lightdm (1.18.2-0ubuntu1) changelog to suggest that it might have addressed this issue.

@michael-thayer: thank you for spending the extra time to confirm that lightdm (1.18.2-0ubuntu1) is still affected.

[Robert Ancell (robert-ancell)]

The initial log contains the following:
[+2.89s] DEBUG: Launching process 888: /usr/bin/X -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
[+5.70s] DEBUG: Process 888 exited with return value 127

And the X log shows:
/usr/lib/xorg/Xorg: symbol lookup error: /var/lib/VBoxGuestAdditions/lib/libEGL.so.1: undefined symbol: RTR3InitDll

Does this always happen when the failure occurs?

[Michael Thayer (michael-thayer)]

My apologies, I missed that one, so this is probably my bug! I will fix that and then get back to you.

[Paul Sladen (sladen)]

Further discussion at:

  https://irclogs.ubuntu.com/2016/07/12/%23ubuntu-devel.html#t15:20

with a pointer to:

  https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/common/crOpenGL/egl.c#L136

And side-discussion of possible better ways of how to detect client GL vs. server GL, which at the moment is using:

  getenv("DISPLAY") != NULL

and a quick look into how the Nvidia driver packaging is handling this in postinst using:

  update-alternatives --force --install /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf x86_64-linux-gnu_gl_conf /usr/lib/nvidia-361/ld.so.conf 8604

[Paul Sladen (sladen)]

This changeset was applied upstream:

  https://www.virtualbox.org/changeset/62201/vbox/trunk/src/VBox/Additions/common/crOpenGL/egl.c

[Michael Thayer (michael-thayer)]

Sorry, that doesn't do it yet. (Shame I didn't manage to fix this for 5.0.0.) However I realised that Mesa has exactly the same problem, so I have taken a look at their code to see what they do. Also looks like a bit of a hack, but since nothing relevant can afford not to work with Mesa it should be a safe one.

[Michael Thayer (michael-thayer)]

I hope this upstream change set will do the trick:

https://www.virtualbox.org/changeset/62242

Re comment 11, I looked at Mesa to see how they were distinguishing client and server GL and applied that to my code (see comments in change set).

To summarise the issue: the tricks that we were playing to prevent the X server from loading our GL libraries, which unlike Mesa are designed to be client only, were not working here, and the X server process was failing when our libraries tried to call a function (RTR3InitDll) in another library which gets loaded by clients but which the X server was not (not sure why). I refined the tricks by studying how Mesa handles detecting being loaded by the server (technically being loaded for use with GBM rather than with X11) and in addition got rid of the immediate dependency which was failing.

Was that at all helpful?