User session does not start: Problem with chrome-remote-desktop

[El jinete sin cabeza]

https://gitlab.freedesktop.org/xorg/app/xkbcomp/-/issues/14
https://gitlab.gnome.org/GNOME/gdm/-/issues/593

---

Today I tried to log into my ubuntu session with my personal account through Xorg and Xwayland. And I couldn't, I had to install lightdm and to be able to enter.

In my experience, I found this message ($journalctl):
Apr 22 09:06:44 romanescu gnome-shell [3651]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Apr 22 09:06:44 romanescu gnome-shell [3651]:> Warning: Unsupported maximum keycode 569, clipping.
Apr 22 09:06:44 romanescu gnome-shell [3651]:> X11 cannot support keycodes above 255.
Apr 22 09:06:44 romanescu gnome-shell [3651]:> Internal error: Could not resolve keysym Invalid
Apr 22 09:06:44 romanescu gnome-shell [3651]: Errors from xkbcomp are not fatal to the X server

Attached log of the attempt to log in.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: gdm3 3.34.1-1ubuntu1
Uname: Linux 5.6.6-050606-generic x86_64
ApportVersion: 2.20.11-0ubuntu27
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Wed Apr 22 09:54:26 2020
InstallationDate: Installed on 2018-12-02 (506 days ago)
InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725)
SourcePackage: gdm3
UpgradeStatus: No upgrade log present (probably fresh install)

[El jinete sin cabeza (ejsc-deactivatedaccount)]

https://gitlab.gnome.org/GNOME/gdm/-/issues/593

[El jinete sin cabeza (ejsc-deactivatedaccount)]

https://gitlab.freedesktop.org/xorg/app/xkbcomp/-/issues/14

[Robert (rspier)]

(the xkbcomp stuff is clearly marked as "Errors from xkbcomp are not fatal to the X server").

This will likely be resolved with the patch from https://gitlab.gnome.org/GNOME/gdm/-/issues/580.

[Robert (rspier)]

https://gitlab.gnome.org/GNOME/gdm/-/issues/580

[Erik Jensen (rkjnsn-g)]

I can confirm that this upstream commit fixes the issue: https://gitlab.gnome.org/GNOME/gdm/-/commit/32646105196ed7a687f3684b69ea544dd01d2ade?merge_request_iid=90

I've attached it as a patch, and verified that it applies cleanly to gdm3-3.34.1 and resolves the issue on Ubuntu 19.10.

Can the patch be applied to the Ubuntu packages?

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "try-looking-up-session-by-pid-first.diff" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Sebastien Bacher (seb128)]

Thanks, patching the login code is always a bit risky so we should probably give those changes some testing in the new cycle first.
How do you end up with several active greeters? It doesn't seem like a common scenario

[Erik Jensen (rkjnsn-g)]

There's only one GDM greeter in this case. The bug is that if there's *any* other PAM/loginctl session for the user of type "x11", GDM will fail to log the user in without the above patch.

When Chrome Remote Desktop starts at boot, it creates such a user session (via PAM) under the user who has configured it. This session is used to run the Chrome Remote Desktop host process, an instance of Xvfb, and, if the user hasn't configured a custom CRD session script to run at boot, a very simple session chooser.

Even if the session only contains sleep 5000, however, its mere presence is enough to break GDM for that user. I experimented with setting the session type used by CRD to "unspecified", but that ended up breaking programs running with the CRD session, so fixing the GDM bug seems to be the only path forward.

[Erik Jensen (rkjnsn-g)]

After some further testing, fixing the GDM bug allows logging into both X11 and Wayland on 19.10 while Chrome Remote Desktop is running, but on 20.04, I cannot start a Wayland while CRD is running (X11 still works once the GDM fix is applied).

Taking a brief look at the logs, it appears there is a separate but similar bug with how Gnome Shell attempts to determine its seat when running as a Systemd user service. My guess it that it is finding the CRD session, which doesn't have a seat, instead of its own, and then failing.

[Daniel van Vugt (vanvugt)]

The above fix was released in gdm3 3.37.1