Bug 739328

Summary: Gnome session breaks immediately on login
Product: [Fedora] Fedora Reporter: Göran Uddeborg <goeran>
Component: gnome-sessionAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 16CC: aurorauddeborg, jmccann, rstrode
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-09-24 20:20:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
.xsession content after a failed login attempt none

Description Göran Uddeborg 2011-09-17 18:21:58 UTC
Created attachment 523720 [details]
.xsession content after a failed login attempt

Description of problem:
When trying to log in to a gnome session an unhappy screen appears with the text "a problem has occurred and the system can not recover" (approximate translation back to English from Swedish).  It happens to both user accounts on the machine.

The assignment of this bug to gnome-session is just a guess.  I don't know what component is the problematic one.

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

How reproducible:
Every time

Steps to Reproduce:
1. Try to log in
Actual results:
Failure screen

Expected results:
A gnome session starting

Additional info:
It is possible to log in to a virtual console screen.  It is also possible to start a graphical login by using the "user script" option and having a .xsession that starts a twm session.

The .xsession-errors file contains a backtrace.  It is labeled with "gdm", though I'm not sure if it means gdm is recording it or if it means gdm itself is crashing.

This machine was upgraded to F16 using yum.  This problem did not appear from the start.  It started after an upgrade done on the 8 of September.  We didn't have time to debug it at the time, and after a new upgrade on the 11:th it started working again.  But after yet another upgrade today the 17:th, the problem is back.  (Or a new problem which looks the same to the end user.)

Comment 1 Göran Uddeborg 2011-09-20 20:41:49 UTC
A few updates:  It doesn't happen "every time", just most of the time.  Occasionally, a session starts.

There is also a correlation with the background image.  Normally, the selected background image is shown for a few moments before the "crash screen" shows up.  But those times when the login succeeds, the background stays the original submarine from the Verne theme.  When bringing up the background selection dialog it shows the expected image to be selected.  Switching to another background image in the dialog has no effect; the real background is not affected.

Maybe that could be a clue.  We will investigate further, but I wanted to forward what we have found so far right away.

Comment 2 Göran Uddeborg 2011-09-24 20:20:08 UTC
The announcement of the delay of the beta release drew our attention to bug 738803.  And sure indeed, after updating selinux-policy, and doing the restorecon suggested in comment 13 of bug 738803 in all accounts, we can log in fine again.

*** This bug has been marked as a duplicate of bug 738803 ***