Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1753191 - Switching from GNOME Classic to GNOME leaves the shell in classic mode
Summary: Switching from GNOME Classic to GNOME leaves the shell in classic mode
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-session
Version: 31
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Benjamin Berg
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker AcceptedFreezeException
Depends On:
Blocks: F31FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2019-09-18 11:42 UTC by Lukas Ruzicka
Modified: 2019-10-29 01:20 UTC (History)
20 users (show)

Fixed In Version: gnome-session-3.34.0-3.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-09-24 15:55:31 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
Journalctl from the affected machine (1.41 MB, text/plain)
2019-09-18 11:44 UTC, Lukas Ruzicka 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
GNOME Gitlab GNOME gnome-shell issues 1598 0 None None None 2019-09-20 16:36:13 UTC

Description Lukas Ruzicka 2019-09-18 11:42:55 UTC 
Description of problem:

In a fresh bare metal installation, I wanted to try the Gnome Classic DE. I created my users using gnome-initil-setup, rebooted the computer and went for Gnome Classic. The attempt to start it ended up in the White Screen "Oops, something went wrong" error and I could only press the logout button. That action brought me back to the GDM screen. 

After that, I chose the Gnome option instead to log into a regular Gnome Session, but I ended up in a Gnome Classic Session. Until I rebooted the computer, I was not able to log into a regular Gnome Session and got the Classic session on the Gnome menu item and a crash screen on Gnome Classic menu item.

Version-Release number of selected component (if applicable):

gnome-shell-3.34.0-1.fc31.x86_64

How reproducible:

Always

Steps to Reproduce:
1. Install fresh Fedora Workstation.
2. Go through the G-I-S and reboot computer.
3. Attempt to use Gnome Classic. => the WSOD
4. Log out and try to login into Gnome => Gnome Classic instead.
5. Repeat step 4 several times. => sometimes it helps, sometimes not
6. Reboot and try to log into the Gnome session => success

Expected results:

Everything should work.

Additional info:

In the journalctl, one possible error line could be found:

Sep 18 13:35:22 localhost.localdomain gdm-password][1500]: gkr-pam: unable to locate daemon control file
Comment 1 Lukas Ruzicka 2019-09-18 11:44:52 UTC 
Created attachment 1616194 [details]
Journalctl from the affected machine
Comment 2 Fedora Blocker Bugs Application 2019-09-18 12:35:09 UTC 
Proposed as a Blocker for 31-final by Fedora user lruzicka using the blocker tracking app because:

 I am proposing, because the by default installed Gnome Classic DE cannot be started normally which violates the Default application functionality.

All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test.

All applications installed by default in Fedora Workstation must comply with each MUST and MUST NOT guideline in the Applications and Launchers policy.
Comment 3 Adam Williamson 2019-09-18 14:57:21 UTC 
-1. Classic is an alternate desktop environment, effectively, it is not an application. We specifically consider it non-blocking in the Desktop validation page:

https://fedoraproject.org/wiki/Test_Results:Fedora_31_Branched_20190918.n.0_Desktop
Comment 4 Christian Fredrik Kalager Schaller 2019-09-19 17:28:13 UTC 
I just hit this issue on my own system too.
Comment 5 Benjamin Berg 2019-09-19 18:26:35 UTC 
Sounds like an environment variable is surviving between sessions. We probably need to explicitly unset it on login to be on the safe side.

As for the WSOD, I did not see anything in the log that would explain why it was started.
Comment 6 Jonathan Haas 2019-09-20 10:46:31 UTC 
(In reply to Adam Williamson from comment #3)
> -1. Classic is an alternate desktop environment, effectively, it is not an
> application.

But it is an element of the "default panel" (of the login screen). It's not good if an option on the login screen just doesn't work (and also breaks the normal Gnome session after that). Gnome Classic may be non-blocking but then at least the option to launch it should be removed (if it doesn't work).
Comment 7 Lukas Ruzicka 2019-09-20 12:56:49 UTC 
(In reply to J. Haas from comment #6)
> (In reply to Adam Williamson from comment #3)
> > -1. Classic is an alternate desktop environment, effectively, it is not an
> > application.
> 
> But it is an element of the "default panel" (of the login screen). It's not
> good if an option on the login screen just doesn't work (and also breaks the
> normal Gnome session after that). Gnome Classic may be non-blocking but then
> at least the option to launch it should be removed (if it doesn't work).

Exactly, this is what I meant, too. I did not know that login issues go into the "Default panel" criteria. I would normally consider this blocking according to the Login/Logout criteria for Beta. Anyway, this is not a behavior I would like to see in the final release.

still +1 blocker
Comment 8 Adam Williamson 2019-09-20 15:21:54 UTC 
The criterion refers to the panel of the *desktop*, not the login screen. Also, the 'panel' is the bar along the top of the screen, for GNOME/GDM purposes. You don't pick the session there.

The login/logout criteria again covers "release-blocking desktops". GNOME Classic isn't one.
Comment 9 Florian Müllner 2019-09-20 16:31:09 UTC 
See https://gitlab.gnome.org/GNOME/gnome-shell/issues/1598 for the upstream issue.

(In reply to Benjamin Berg from comment #5)
> Sounds like an environment variable is surviving between sessions. We
> probably need to explicitly unset it on login to be on the safe side.

GDM unsets session variables at login:
https://gitlab.gnome.org/GNOME/gdm/blob/master/daemon/gdm-wayland-session.c

But that only changes the environment for gnome-session and its children, not any processes spawned by the systemd user instance.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/714 addresses the issue on the gnome-shell side, but I'd rather keep writing that environment variable in a single component (read: GDM) if possible.
Comment 10 Benjamin Berg 2019-09-20 18:49:44 UTC 
> GDM unsets session variables at login

Yeah, but we upload variables to systemd from gnome-session-binary. So if the variable is not set, then it might survive across session in the systemd user instance.
Comment 11 Benjamin Berg 2019-09-23 11:34:26 UTC 
I created a scratch build for the upstream fix from https://gitlab.gnome.org/GNOME/gnome-session/merge_requests/23

https://koji.fedoraproject.org/koji/taskinfo?taskID=37821641

I believe this will fix the issue that the classic mode is sticky between session (verified by checking the variable gets unset in my jhbuild environment).

As for the classic mode failure, I'll do a few tests and see if I can reproduce it.
Comment 12 Benjamin Berg 2019-09-23 12:16:07 UTC 
The WSOD will be fixed by a gnome-shell-extensions update (gnome-classic-session package). The upstream fix for this is https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/94.

Due to this, a few of the required components were entirely missing, causing the session to fail immediately.


I have submitted a PR to fix gnome-session https://src.fedoraproject.org/rpms/gnome-session/pull-request/4 and verified that this fixes the issue here.
Comment 13 Fedora Update System 2019-09-23 12:31:19 UTC 
FEDORA-2019-77b1991791 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-77b1991791
Comment 14 Christian Fredrik Kalager Schaller 2019-09-23 14:40:25 UTC 
Just tested the new build, so the fix does resolve the issue of still being in Classic mode when logging back into standard mode, but the issue of the Classic session giving an Opps, something went wrong is still there.
Comment 15 Geoffrey Marr 2019-09-23 17:52:10 UTC 
Discussed during the 2019-09-23 blocker review meeting: [0]

The decision to classify this bug as a "RejectedBlocker" and an "AcceptedFreezeException" was made as, Classic being a non-release-blocking desktop and desktop selection in GDM not being part of the GNOME 'panel', it doesn't violate any criteria. Accepted as an FE as it's a visible bug we would like to avoid being seen out-of-the-box for Final.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-09-23/f31-blocker-review.2019-09-23-16.03.txt
Comment 16 Fedora Update System 2019-09-24 01:23:58 UTC 
gnome-session-3.34.0-3.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-77b1991791
Comment 17 Kamil Páral 2019-09-24 08:46:08 UTC 
I'm quite sure this was supposed to target Final, not Beta (already out), fixing tags.
Comment 18 Fedora Update System 2019-09-24 15:55:31 UTC 
gnome-session-3.34.0-3.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.
Comment 19 Adam Williamson 2019-10-29 01:20:54 UTC 
Clearing CommonBugs as we fixed this ahead of Final.
Note You need to log in before you can comment on or make changes to this bug.