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):
Steps to Reproduce:
1. Try to log in
A gnome session starting
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.)
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.
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 ***