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):
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
Everything should work.
In the journalctl, one possible error line could be found:
Sep 18 13:35:22 localhost.localdomain gdm-password]: gkr-pam: unable to locate daemon control file
Created attachment 1616194 [details]
Journalctl from the affected machine
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.
-1. Classic is an alternate desktop environment, effectively, it is not an application. We specifically consider it non-blocking in the Desktop validation page:
I just hit this issue on my own system too.
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.
(In reply to Adam Williamson from comment #3)
> -1. Classic is an alternate desktop environment, effectively, it is not an
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).
(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
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.
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:
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.
> 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.
I created a scratch build for the upstream fix from https://gitlab.gnome.org/GNOME/gnome-session/merge_requests/23
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.
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.
FEDORA-2019-77b1991791 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-77b1991791
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.
Discussed during the 2019-09-23 blocker review meeting: 
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.
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
I'm quite sure this was supposed to target Final, not Beta (already out), fixing tags.
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.
Clearing CommonBugs as we fixed this ahead of Final.