Project

General

Profile

Bug #11442

The Greeter is not displayed on Stretch

Added by intrigeri about 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
High
Assignee:
-
Category:
-
Target version:
Start date:
05/18/2016
Due date:
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Greeter

Description

Instead I see the regular GDM greeter.

Associated revisions

Revision c418c05c (diff)
Added by intrigeri almost 3 years ago

Fully disable the test suite.

It's just wasting time on Jenkins currently, since on feature/stretch
our Greeter does not work well enough to allow testing anything yet.

refs: #11442

History

#1 Updated by intrigeri about 3 years ago

Note that one still can log in with the "live" password.

#2 Updated by intrigeri about 3 years ago

On Jessie, gdm3 ships /usr/share/gnome-session/sessions/gdm-shell.session, but in Stretch it doesn't, so it's no big surprise that our own /usr/share/gnome-session/sessions/gdm-tails.session is not used.

Indeed, the GDM -speficic GNOME session and desktop file are gone:

commit 26006da375bc38afb270296e927d71180f6bed01
Author: Ray Strode <rstrode@redhat.com>
Date:   Mon Nov 9 10:57:16 2015 -0500

    data: drop override xsession files

    We now tell gnome-shell to use GDM mode a different
    way so we don't need to override the desktop files
    anymore.

    https://bugzilla.gnome.org/show_bug.cgi?id=757715

commit f66cdfcb29482bb3267f19de7c57394fe8189f39
Author: Ray Strode <rstrode@redhat.com>
Date:   Tue Feb 17 11:56:36 2015 -0500

    data: drop gdm-shell.session

    It's identical to gnome.session these days.  All GDMification comes
    from the overriden gnome-shell.desktop file.

    https://bugzilla.gnome.org/show_bug.cgi?id=744764

To see how it works nowadays: git grep -E -i '(gdm[_-]mode|launch_environment|session[_-]mode|session_class|isGreeter)' in GNOME Shell and GDM Git trees.

The login UI code lives in js/gdm/ in the GNOME Shell (yes!) repo nowadays. The components to run, depending on the mode (e.g. "gdm", "lock-screen", "user") are listed in js/ui/sessionMode.js. Maybe we can patch this file to have the "gdm" mode start our greeter and hide the login dialog (with unlockDialog: undefined possibly)?

#3 Updated by intrigeri about 3 years ago

  • Priority changed from Elevated to High

(This blocks a lot of other 3.0-related work.)

#4 Updated by intrigeri about 3 years ago

intrigeri wrote:

The login UI code lives in js/gdm/ in the GNOME Shell (yes!) repo nowadays. The components to run, depending on the mode (e.g. "gdm", "lock-screen", "user") are listed in js/ui/sessionMode.js. Maybe we can patch this file to have the "gdm" mode 1. start our greeter and 2. hide the login dialog (with unlockDialog: undefined possibly)?

Instead of patching that JS to make it start our Greeter (1), we could would be to configure the default gnome.session's RequiredComponents= to always start our Greeter, via a wrapper that exits 0 when we're not in GDM mode. Still, we need to patch GNOME Shell to tell it not to display its login screen (2), if it oherwise hides our own one; this can be done as suggested in the quoted text.

Another idea to solve both (1) and (2) would be to add a new mode (see /usr/share/gnome-shell/modes/classic.json) that would inherits from the "gdm" mode, and enable the component/extension we need. But asking GDM to tell GNOME Shell that we're in $mode is a bit complicated: GDM defines its mode in GDM_SESSION_MODE in daemon/gdm-launch-environment.c to gdm. So, for this idea to work, we need to patch GDM.

Note that we can't ship /usr/share/gnome-shell/modes/gdm.json since if we got the code right, loads _modes from its own source code first, and then doesn't allow overriding an existing mode via $mode.json: it only allows inheriting from a parent mode, which is not a perfect solution for the Greeter's use case as explained before.

#5 Updated by intrigeri almost 3 years ago

On my today's build of feature/stretch, I see the Greeter. It's quite buggy though: no background picture, empty list of keyboard layouts, and once I click "Login" X disappears and I'm back on a text console. But then I can reach the GNOME session with CTRL+ALT+F2.

#6 Updated by alant almost 3 years ago

I have been suggested at GUADEC to use the gnome-initial-setup infrastructure to plug our greeter in.

The conditions for it to be launched are in daemon/gdm-display.c:1426(wants_initial_setup), and is basically:

  • no user accounts available (could we satisfy that?)
  • gnome-initial-setup.session is available
  • configuration key daemon/InitialSetupEnable is True

Then, daemon/gdm-launch-environment.c will connect as gnome-initial-setup with the session /usr/share/gnome-session/sessions/gnome-initial-setup.session (provided by debian package gnome-initial-setup), with a shell session mode initial setup (that should be OK for us).

To start a session gnome-initial-setup connects to GDM in gnome-initial-setup/pages/summary/gis-summary-page.c:176(log_user_in):

  • gdm_client_get_greeter_sync
  • gdm_client_get_user_verifier_sync
  • gdm_user_verifier_call_begin_verification_for_user_sync

Good news is that gnome-initial-setup is an real GTK+ binary, as our greeter is. So tails-greeter could conflict with the gnome-initial-setup package and provide the gnome-initial-setup.session. We would then use a maintained way to plug in the greeter.

#7 Updated by intrigeri almost 3 years ago

alant wrote:

I have been suggested at GUADEC to use the gnome-initial-setup infrastructure to plug our greeter in.

This might be a good idea on the long term, but as said earlier the Greeter now shows up, so I doubt we'll need this for Stretch => please track this elsewhere if you want, since this ticket is going away :)

#8 Updated by intrigeri almost 3 years ago

  • Status changed from Confirmed to Resolved
  • % Done changed from 0 to 100

Remaining issues are tracked as #11693, #11694 and #11695 => closing this ticket.

Also available in: Atom PDF