Bug 1753191

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:

https://fedoraproject.org/wiki/Test_Results:Fedora_31_Branched_20190918.n.0_Desktop

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
> 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).

(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:
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.

> 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

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.

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: [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

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.