Created attachment 998157 [details] dmesg log, top output, and Xorg.0.log After upgrading from a working FC19 to FC21 via fedup, the screen goes blank instead of presenting the Gnome login screen. Version-Release number of selected component (if applicable): dnf list installed | egrep -i '(kernel|gdm|nvidia)' reports: abrt-addon-kerneloops.x86_64 2.3.0-3.fc21 @System akmod-nvidia-304xx.x86_64 304.125-1.fc21.1 @System gdm.x86_64 1:3.14.1-2.fc21 @System kernel.x86_64 3.18.7-200.fc21 @System kernel-core.x86_64 3.18.7-200.fc21 @System kernel-devel.x86_64 3.18.7-200.fc21 @System kernel-headers.x86_64 3.18.7-200.fc21 @System kernel-modules.x86_64 3.18.7-200.fc21 @System kernel-tools.x86_64 3.18.7-200.fc21 @System kernel-tools-libs.x86_64 3.18.7-200.fc21 @System kmod-nvidia-304xx-3.18.7-200.fc21.x86_64.x86_64 libreport-plugin-kerneloops.x86_64 2.3.0-5.fc21 @System pulseaudio-gdm-hooks.x86_64 5.0-25.fc21 @System xorg-x11-drv-nvidia-304xx.x86_64 304.125-1.fc21 @System xorg-x11-drv-nvidia-304xx-libs.x86_64 304.125-1.fc21 @System lspci | fgrep VGA reports: 01:00.0 VGA compatible controller: NVIDIA Corporation G72 [GeForce 7300 LE] (rev a1) How reproducible: Steps to Reproduce: 1. Upgrade from FC19 to FC21 2. Reboot Actual results: Blank screen, no filling Fedora logo and no Gnome login screen. gnome-shell using up to 100% of the CPU. Expected results: Filling Fedora logo, Gnome login screen, no major CPU usage. Additional info: After the white/blue progress bar completes, the screen goes blank. I do not see the Fedora logo filling up. I can use CTRL-ALT-F2 to get to the console. gnome-session and Xorg.bin are running. I see a gnome-shell process using 93-100% of the CPU. Following a suggestion, I installed LXDE. I stopped gdm and started lxde and I get a usable login screen, suggesting that it is gdm not the display driver causing the problem. I am using akmod-nvidia-304xx. If I try to use the nouveau driver, once gdm starts, instead of a blank screen I get the last output from the text boot displayed in the upper-left quarter of the display (640x480 at a guess) but I cannot use CTRL-ALT-F2 to get to the console. It is frozen. So there is probably more than one upgrade issue to resolve. Apart from the display, the system appears to be functioning normally. I've attached the output from dmesg, "top" and Xorg.0.log
Many similar problems with Gnome-related things not working after upgraded from Fedora 20 to Fedora 21 are presented in forums.fedoraforum.org > "Installation"-category: http://forums.fedoraforum.org/forumdisplay.php?f=6 But if Gnome is avoided (eg. with LXDE), graphics works. Many reported as "nvidia causing black screen", but I am not sure it is really related to nvidia drivers or settings. I also was able to use kdm, lxdm and LXDE, but not gdm, gnome-session, gnome classic session. If anything Gnome-related started, mouse pointer quickly went away and the GUI became unresponsive to mouse and keyboard. I have an "educated feeling" it has something to do about permissions of input devices, mouse and keyboard and with Gnome. The output of X-server log Xorg.0.log didn't differ when kdm+Gnome didn't work, compared to kdm+LXDE did work. I somehow got my problem fixed eventually after ~1 month of testing different things time to time when I felt like it. During that time I used LXDE: http://forums.fedoraforum.org/showthread.php?t=302981 It started to work after: sudo chmod -R o+rwX /dev/input Then Gnome-session started from kdm worked. I got a Gnome initial settings diaglog wizard and then log out (kdm), log in (gdm), and Gnome worked. After that also gdm started to work. What is weird, even after reboot when permissions of /dev/input/* are reset, it still works. Only thing which still behaves the same, if I start Gnome Wayland session from gdm. Maybe a experiment with getting Gnome to work under Wayland has caused this bug? Even if Wayland is not used, it somehow messes things up. If I change "True" values to "False" in /etc/X11/xorg.conf.d/00-server-flags.conf I seem to get similar non working mouse+keyboard state in X: # cat /etc/X11/xorg.conf.d/00-server-flags.conf Section "ServerFlags" Option "AllowEmptyInput" "True" Option "AutoAddDevices" "True" EndSection
Created attachment 998253 [details] Output of EACCES or ENOENT system calls of strace -ff gdm during failed start It was difficult to get any error messsages or logging out of gdm when it did not work. /var/log/gdm/ didn't get anything. Syslog (journald) got very little useful. When Gnome and gdm was not yet working, I once started gdm as root under strace -ff This is a output of those strace debug files by grepping EACCES or ENOENT failed system calls with: grep -E "EACCESS|ENOENT" gdm.* Maybe someone who has developed gdm, can see what is the problem. I also have similar strace -ff output of non working gnome-session process. Having these two lines in /etc/gdm/custom.conf may help to get some more information out of gdm to syslog: [debug] Enabled=true
Created attachment 998256 [details] Output of lines with EACCES or ENOENT of output of strace -ff gnome-session this was done by renaming /usr/bin/gnome-session to /usr/bin/gnome-session.bin and having ... /usr/local/bin/gnome-session: #!/bin/sh mkdir /tmp/gnome-session.strace cd /tmp/gnome-session.strace strace -ff -o gnome-session.strace -e open /bin/gnome-session.bin --debug What puzzels me, why gnome-session would need access to execmem? Accelerated graphics stuff with nvidia? Closed source mystery code? gnome-session.3480:open("/sys/fs/selinux/booleans/allow_execmem", O_RDONLY) = -1 ENOENT (No such file or directory) There is no EACCESS errors to /dev/input/ though, which was my hypothesis what could be wrong.
Earlier bug 1195074 seems to be concerning the same issue. Both gdm and also gnome-session (started without gdm) fail in the same way (ie. no mouse pointer).
sudo chmod -R o+rwX /dev/input didn't help me to start gnome-shell session :(
This problem appears to be resolved by libselinux-2.3-9.fc21 which in the testing repository now. See Bug #1195074.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is 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 change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.