Created attachment 501286 [details] .xsession-errors with default configuration Description of problem: I cannot login to GNOME - GUI freezes at password enter step after entering user name and pressing enter. If I press Ctrl+Alt+BackSpace, I can enter user name and password, enters my session - and then GUI freezes again, forever. No matter what session I'm choosing - GNOME or fallback. However I can successfully login with Xrdp (of course, with fallback session on Gallium 0.4). I can login with xorg.conf deleted (again, fallback - and I have to Ctrl+Alt+BackSpace freezed password dialog). I have two LCD's connected to my video card. Version-Release number of selected component (if applicable): Fedora was upgraded from F14 with yum (no errors in logs). I use NVidia 270.41.19 drivers from NVidia's site (with xorg.conf in place) or default drivers from F15 (without xorg.conf - not sure if it is nouveau, as it is blacklisted). How reproducible: Always. Steps to Reproduce: 1. Not sure - suppose it is specific. 2. 3. Actual results: GUI freezes, PC unusable in GUI mode. Expected results: Normal GNOME 3 operations. Additional info:
Created attachment 501290 [details] XOrg log with default configuration after nvidia-xconfig
Created attachment 501353 [details] GDM errors logged in /var/log/messages I believe I've reproduced this issue using the following environment: - Fedora 15 x86_64 (updated as of 2011-05-27 13:55 EDT) - NIS authentication enabled - /home directories managed by autofs The following steps will reliably reproduce the GDM hang in my environment: 1) Boot the system. 2) Log in as an NIS user. 3) Password prompt freezes, messages in attachment appear in /var/log/messages. The following workaround allows me to log in using the NIS account: 1) Switch to a text virtual console. 2) Log in as root. 3) Execute: service autofs restart 4) Switch to the GDM virtual console. 5) CTRL-ALT-Backspace 6) Log in as NIS user. At this point, the NIS user login succeeds.
I do not use autofs (completely - no such service) but confirm that freeze on password entering dialog occurs only for 'remote' (winbind/Kerberos/LDAP in my case) users.
I believe I've resolved the autofs issue - ended up being related to a problem with the idmapd configuration on the system. The GDM freeze issue still occurs, however. When the freeze occurs, all I need to do in order to work around the problem is CTRL-ALT-Backspace to restart GDM. Subsequent logins work fine. Interestingly, I need to "kill -9" the GDM process after successfully logging in as an NIS user or else the gdm-greeter will consume all CPU and the GUI will slow to a halt. The first time this slowdown occurred, I had to switch to a text virtual console to kill the process. The GUI became responsive immediately after the process was killed. This problem could be a different issue or it could be related to the freeze during login. Cyril, the runaway process could explain the GUI freeze you describe after a successful login. Try running 'top' after successfully logging in, and if the gdm-greeter is consuming a lot of CPU, see if running 'kill -9' against its PID will avoid the freeze.
John, it is not so simple for me. I have seen gdm-greeter on top and consuming all CPU resources, and I've tried to kill it. The result was black screen in X virtual terminal with mouse cursor (which I was able to move). I've rolled back to F14 and tried to run 'gnome-shell --replace' - got same result and additional bonus: now I have to add 'metacity --replace' in autostart to get working GNOME environment. If not - I'm getting the same freeze.
I'm currently running GNOME 3 in fallback mode since I have a VM whose video card's 3D capability is not supported by the driver. I wonder if the fact that my system is in fallback mode could explain the difference in behavior between killing the gdm-greeter in our environments.
The hang issue that requires the CTRL-ALT-Backspace issue no longer occurs after a 'yum upgrade' and a reboot this morning. The following packages were upgraded: Jun 10 09:12:24 Updated: poppler-0.16.6-1.fc15.x86_64 Jun 10 09:12:25 Updated: liberation-fonts-common-1.07.0-1.fc15.noarch Jun 10 09:12:42 Updated: evolution-3.0.2-2.fc15.x86_64 Jun 10 09:12:42 Updated: poppler-glib-0.16.6-1.fc15.x86_64 Jun 10 09:12:42 Updated: sssd-client-1.5.8-1.fc15.x86_64 Jun 10 09:12:46 Updated: sssd-1.5.8-1.fc15.x86_64 Jun 10 09:12:46 Updated: poppler-utils-0.16.6-1.fc15.x86_64 Jun 10 09:12:53 Updated: evolution-help-3.0.2-2.fc15.noarch Jun 10 09:12:53 Updated: evolution-NetworkManager-3.0.2-2.fc15.x86_64 Jun 10 09:12:56 Updated: liberation-serif-fonts-1.07.0-1.fc15.noarch Jun 10 09:13:00 Updated: liberation-sans-fonts-1.07.0-1.fc15.noarch Jun 10 09:13:01 Updated: liberation-mono-fonts-1.07.0-1.fc15.noarch Jun 10 09:13:02 Updated: poppler-qt-0.16.6-1.fc15.x86_64 The sssd and sssd-client packages are the only ones that appear to be related. sssd - upgraded from 1.5.7-1.fc15.x86_64 to 1.5.8-1.fc15.x86_64 sssd-client - upgraded from 1.5.7-1.fc15.x86_64 to 1.5.8-1.fc15.x86_64
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping