Red Hat Bugzilla – Bug 1527145
GDM Session Selector won't show gnome-classic session as selected
Last modified: 2018-05-30 14:06:31 EDT
Description of problem: When you are choosing between GNOME, GNOME Classic and Custom at the GDM screen, GNOME is shown as selected by default even though Classic is truly selected. How reproducible: Seemingly 100% Steps to Reproduce: 1. Boot a new install of RHEL 7.5 into the GDM screen. 2. Click the session selection gear button. 3. Notice that the dot is next to GNOME, showing the selection. 4. Without changing the selection, log in. Actual results: You will be logged into GNOME Classic (by default) even though GNOME was shown as the selection by the dot next to it. In order to log in to GNOME, you need to select GNOME Classic then GNOME again and log in. Expected results: Session selector should reflect true selection.
I have seen similar problem on rhel-7.5 clean install. I wanted to login to KDE session - it was already selected (based on the dot) in session greeter but I always got logged into GNOME Classsic. I try to select Classic and then KDE, but that didn't help. I had to select GNOME, login and then after logout I was able to login to KDE.
The problem is with the gnome-classic session. If its the default or saved session, it's not properly selected/highlighted in the session chooser. In my case it shows instead the first session in the list which is KDE. This results in two problems. First it's confusing as user might think that it's logging into KDE when he actually uses gnome classic and second you can't select the KDE, because clicking already selected session won't change it. So you have to select different session and then select back the KDE. The other sessions works fine, i.e. if selected they stays selected after logout. Reproducer: 1) Install KDE 2) create new user 3) select the newly created user 4) check the session selector 5) login/logout 7) choose Gnome 8) login/logout 9) choose Gnome classic 10) login/logout It shows the first session which is KDE, but logs you into the gnome classic. And after choosing different session and back gnome classic, it still shows KDE as selected session.
Created attachment 1392725 [details] debug log This is the first login of a new user. The KDE session is selected in the session chooser but the user logs into gnome classic [snip] gdm[1041]: GdmSession: checking if file 'gnome-classic.desktop' is wayland session: no gdm[1041]: GdmSession: Setting user: 'test2' gdm[1041]: GdmSession: Beginning initialization gdm[1041]: GdmSession: Conversation started gdm-password][11406]: AccountsService: ActUserManager: trying to track new user with username test2 gdm-password][11406]: AccountsService: ActUserManager: finding user 'test2' state 1 gdm-password][11406]: AccountsService: ActUserManager: finding user 'test2' state 2 gdm-password][11406]: AccountsService: ActUserManager: Looking for user 'test2' in accounts service gdm-password][11406]: AccountsService: ActUserManager: Found object path of user 'test2': /org/freedesktop/Accounts/User1001 gdm-password][11406]: AccountsService: ActUserManager: finding user 'test2' state 3 gdm-password][11406]: AccountsService: ActUserManager: user 'test2' fetched gdm-password][11406]: AccountsService: ActUserManager: user test2 is now loaded gdm-password][11406]: AccountsService: ActUserManager: user test2 was not yet known, adding it gdm-password][11406]: AccountsService: ActUserManager: tracking user 'test2' gdm-password][11406]: AccountsService: ActUserManager: loaded, so emitting user-added signal gdm-password][11406]: AccountsService: ActUserManager: no pending users, trying to set loaded property gdm-password][11406]: AccountsService: ActUserManager: already loaded, so not setting loaded property gdm-password][11406]: GdmSessionSettings: saved session is gdm-password][11406]: GdmSessionWorker: Saved session is gdm-password][11406]: GdmSessionSettings: saved language is gdm-password][11406]: GdmSessionWorker: Saved language is gdm-password][11406]: GdmSessionWorker: queuing setup for user: test2 (null) gdm-password][11406]: AccountsService: ActUserManager: finished handling request for user 'test2' gdm-password][11406]: AccountsService: ActUserManager: unrefing manager owned by fetch user request gdm-password][11406]: GdmSessionWorker: attempting to change state to SETUP_COMPLETE gdm-password][11406]: GdmSessionWorker: initializing PAM; service=gdm-password username=test2 seat=seat0 gdm[1041]: GdmSession: getting session command for file '.desktop' gdm[1041]: GdmSession: File '.desktop' not found: Valid key file could not be found in search dirs gdm[1041]: GdmSession: not using invalid .dmrc session: gdm[1041]: GdmSession: getting session command for file 'gnome-classic.desktop' gdm[1041]: GdmSession: checking if file 'gnome-classic.desktop' is wayland session: no
pretty sure i have an old patch in bugzilla for this. need to find it tomorrow, but devack+
*** Bug 1538070 has been marked as a duplicate of this bug. ***
Created attachment 1396122 [details] loginDialog: only emit session-activated on user action Right now we emit session-activated any time the bullet moves in the session menu. That includes at start up when picking an item arbitrarily, and any time GDM reports the session was read from the user's account settings. session-activated informs GDM about the newly selected session, so emitting it in response to GDM reporting a session is a bad idea (it's not only pointless, but it can least to oscillations) This commit changes the code to only emit session-activated when the user explicitly activates a session item from the gear menu.
Created attachment 1396141 [details] Revert "session: don't call gdm_session_defaults_changed from setup" This reverts commit 572a19324b75cc1f1b2db4908e2d7c9f06e4e335. It turns out we need this call for more than just the session type, we also need to it to inform the greeter about the default session
so there are two halves to this fix. one for gnome-shell and one for gdm.
I can confirm that the selector now works as expected on gnome-shell-3.26.2-5.el7 and gdm-3.26.2.1-5.el7.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0770
*** Bug 1184915 has been marked as a duplicate of this bug. ***