Description of problem: When booting into a new kernel on Fedora 21 Workstation the system appears to boot but the display is blank (where the previous kernel displays the graphical boot logo). When booting is apparently complete (disk stops spinning etc.) the display remains blank. The system responds to keypresses; in particular, <alt><F2> then <alt><ctl><del> results in more disk spinning etc. as though shutting down, whereas not doing <alt><F2> first does not. If booted with "rhgb quiet" removed from the kernel command line, the initial boot messages are displayed but the startup messages from systemd (?) are not. Version-Release number of selected component (if applicable): kernel-3.18.3-201.fc21.x86_64 How reproducible: Every time Steps to Reproduce: 1. Reboot 2. Pick kernel 3.18.3 Actual results: Blank screen, possibly working system otherwise Expected results: Login screen Additional info:
Hardware is Asus X200M notebook PC http://www.asus.com/Notebooks_Ultrabooks/X200MA/specifications/ F21 Workstation is a fresh installation as of a week ago
One more precision: It appears to be a very simple issue with display. You can workaround the issue by putting your laptop to sleep. * boot and wait for some time so the computer likely reached the login screen * short-press the power button so it goes to sleep mode * short-press the power button to wake it up and the login screen will display
Issue still present in 3.18.6-200.fc21.x86_64
I am also encountering this problem after an upgrade from FC19 to FC21 via fedup on a Dell desktop system. After the progress bar at the bottom of the display completes I get the black screen and no filling tear-drop graphical boot display. I can connect to the system remotely via ssh and everything else appears to be working. The last message in /var/log/boot is: [ OK ] Started GNOME Display Manager. ps shows both Xorg.bin, gnome-session and gnome-settings-daemon running. One curiosity is that is also shows a gnome-shell running having consumed 1355:35 while the other gnome processes are at zero. I just re-booted and a gnome-shell process is already racking up time pretty quickly. The only warnings/errors that seem display-related from the journal from the boot just now are: Feb 19 14:45:24 clowder kernel: nvidia: module license 'NVIDIA' taints kernel. Feb 19 14:45:24 clowder kernel: nvidia: module verification failed: signature and/or required key missing - tainting kernel Feb 19 14:45:24 clowder kernel: [drm] Initialized nvidia-drm 0.0.0 20140818 for 0000:01:00.0 on minor 0 ... Feb 19 14:52:22 clowder gdm-Xorg-:0[2749]: (EE) systemd-logind: failed to get session: PID 2749 does not belong to any known session ... Feb 19 14:52:22 clowder gdm-Xorg-:0[2749]: (WW) NVIDIA(0): Unable to support custom viewPortOut 1920 x 1080 +0 +0 ... Feb 19 14:52:22 clowder gdm-Xorg-:0[2749]: (WW) evdev: Logitech USB Keyboard: ignoring absolute axes. If I disable the nvidia driver and use nouveau instead, I don't even get the black screen; the display "freezes" after the last message from the progress bar. (Very small in the upper-left corner of the display.) I am running 3.18.7-200.fc21.x86_64 If there's any other information I can provide that would help resolve this, just let me know.
@ IVOR -- nouveau or nvidia blobs in play ? / what sort of time commit is yours showing (Ivor's last comment) @Quentin /IVOR does nomodeset getting a working desktop
(In reply to Corey Sheldon from comment #5) > @ IVOR -- nouveau or nvidia blobs in play ? / what sort of time commit is > yours showing (Ivor's last comment) > > @Quentin /IVOR does nomodeset getting a working desktop Not sure about blobs. Here's what is installed: akmod-nvidia-304xx.x86_64 304.125-1.fc21.1 @System kmod-nvidia-304xx-3.18.7-200.fc21.x86_64.x86_64 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 If you are referring to the gnome-shell CPU usage, here is the top of "top" which shows high gnome-shell CPU usage in the 13 mins the system was up after the nomodeset boot test: top - 08:46:30 up 13 min, 2 users, load average: 1.04, 1.18, 0.89 Tasks: 204 total, 2 running, 202 sleeping, 0 stopped, 0 zombie %Cpu(s): 56.0 us, 1.9 sy, 0.0 ni, 38.5 id, 3.4 wa, 0.0 hi, 0.1 si, 0.0 st KiB Mem : 3979952 total, 2275356 free, 421044 used, 1283552 buff/cache KiB Swap: 4128764 total, 4128764 free, 0 used. 3324768 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1936 gdm 20 0 395564 15088 13508 R 93.8 0.4 12:17.23 gnome-shell 3896 durham 20 0 146484 3820 3260 R 6.2 0.1 0:00.02 top Here's the nomodeset command line from the log which did not change the black screen behaviour: [ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.18.7-200.fc21.x86_64 root=/dev/mapper/vg_clowder-lv_root ro rd.md.uuid=d81bbcb8:a61669c8:c183b918:69fe889c LANG=en_US.UTF-8 SYSFONT=True KEYTABLE=us rd.md.uuid=03bd61b0:56dd94bc:96264ee9:d4efd94d rd.luks=0 rd.lvm.lv=vg_clowder/lv_swap rd.lvm.lv=vg_clowder/lv_root rd.dm=0 rhgb quiet nomodeset Xorg.bin, gnome-session etc. are all running. <alt>F2 gets me to the text login prompt. The first visual anomaly is that I don't even see the filling tear-drop logo once gdm starts after the blue/white progress bar completes.
(In reply to Ivor Durham from comment #6) > (In reply to Corey Sheldon from comment #5) > > @ IVOR -- nouveau or nvidia blobs in play ? / what sort of time commit is > > yours showing (Ivor's last comment) > > > > @Quentin /IVOR does nomodeset getting a working desktop > > Not sure about blobs. Here's what is installed: > > akmod-nvidia-304xx.x86_64 304.125-1.fc21.1 > @System > kmod-nvidia-304xx-3.18.7-200.fc21.x86_64.x86_64 > 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 > > If you are referring to the gnome-shell CPU usage, here is the top of "top" > which shows high gnome-shell CPU usage in the 13 mins the system was up > after the nomodeset boot test: > > top - 08:46:30 up 13 min, 2 users, load average: 1.04, 1.18, 0.89 > Tasks: 204 total, 2 running, 202 sleeping, 0 stopped, 0 zombie > %Cpu(s): 56.0 us, 1.9 sy, 0.0 ni, 38.5 id, 3.4 wa, 0.0 hi, 0.1 si, 0.0 > st > KiB Mem : 3979952 total, 2275356 free, 421044 used, 1283552 buff/cache > KiB Swap: 4128764 total, 4128764 free, 0 used. 3324768 avail Mem > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 1936 gdm 20 0 395564 15088 13508 R 93.8 0.4 12:17.23 > gnome-shell > 3896 durham 20 0 146484 3820 3260 R 6.2 0.1 0:00.02 top > > Here's the nomodeset command line from the log which did not change the > black screen behaviour: > > [ 0.000000] Kernel command line: > BOOT_IMAGE=/vmlinuz-3.18.7-200.fc21.x86_64 > root=/dev/mapper/vg_clowder-lv_root ro > rd.md.uuid=d81bbcb8:a61669c8:c183b918:69fe889c LANG=en_US.UTF-8 SYSFONT=True > KEYTABLE=us rd.md.uuid=03bd61b0:56dd94bc:96264ee9:d4efd94d rd.luks=0 > rd.lvm.lv=vg_clowder/lv_swap rd.lvm.lv=vg_clowder/lv_root rd.dm=0 rhgb quiet > nomodeset > > Xorg.bin, gnome-session etc. are all running. <alt>F2 gets me to the text > login prompt. The first visual anomaly is that I don't even see the filling > tear-drop logo once gdm starts after the blue/white progress bar completes. Proprietary drivers are not supported by fedora, and this bug report is most likely unrelated to your problem, this seems to be specific to some asus notebooks. (And specification of the hardware that reported posted link to, doesn't have nvidia graphics in it)
(In reply to (bitlord) from comment #7) > (In reply to Ivor Durham from comment #6) > > (In reply to Corey Sheldon from comment #5) > > > @ IVOR -- nouveau or nvidia blobs in play ? / what sort of time commit is > > > yours showing (Ivor's last comment) > > > > > > @Quentin /IVOR does nomodeset getting a working desktop > > > > Not sure about blobs. Here's what is installed: > > > > akmod-nvidia-304xx.x86_64 304.125-1.fc21.1 > > @System > > kmod-nvidia-304xx-3.18.7-200.fc21.x86_64.x86_64 > > 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 > > > > If you are referring to the gnome-shell CPU usage, here is the top of "top" > > which shows high gnome-shell CPU usage in the 13 mins the system was up > > after the nomodeset boot test: > > > > top - 08:46:30 up 13 min, 2 users, load average: 1.04, 1.18, 0.89 > > Tasks: 204 total, 2 running, 202 sleeping, 0 stopped, 0 zombie > > %Cpu(s): 56.0 us, 1.9 sy, 0.0 ni, 38.5 id, 3.4 wa, 0.0 hi, 0.1 si, 0.0 > > st > > KiB Mem : 3979952 total, 2275356 free, 421044 used, 1283552 buff/cache > > KiB Swap: 4128764 total, 4128764 free, 0 used. 3324768 avail Mem > > > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > 1936 gdm 20 0 395564 15088 13508 R 93.8 0.4 12:17.23 > > gnome-shell > > 3896 durham 20 0 146484 3820 3260 R 6.2 0.1 0:00.02 top > > > > Here's the nomodeset command line from the log which did not change the > > black screen behaviour: > > > > [ 0.000000] Kernel command line: > > BOOT_IMAGE=/vmlinuz-3.18.7-200.fc21.x86_64 > > root=/dev/mapper/vg_clowder-lv_root ro > > rd.md.uuid=d81bbcb8:a61669c8:c183b918:69fe889c LANG=en_US.UTF-8 SYSFONT=True > > KEYTABLE=us rd.md.uuid=03bd61b0:56dd94bc:96264ee9:d4efd94d rd.luks=0 > > rd.lvm.lv=vg_clowder/lv_swap rd.lvm.lv=vg_clowder/lv_root rd.dm=0 rhgb quiet > > nomodeset > > > > Xorg.bin, gnome-session etc. are all running. <alt>F2 gets me to the text > > login prompt. The first visual anomaly is that I don't even see the filling > > tear-drop logo once gdm starts after the blue/white progress bar completes. > > Proprietary drivers are not supported by fedora, and this bug report is most > likely unrelated to your problem, this seems to be specific to some asus > notebooks. (And specification of the hardware that reported posted link to, > doesn't have nvidia graphics in it) I will note that it fails with the nouveau driver too. Should I re-post as a separate bug?
(In reply to Ivor Durham from comment #8) > (In reply to (bitlord) from comment #7) > > (In reply to Ivor Durham from comment #6) > > > (In reply to Corey Sheldon from comment #5) > > > > @ IVOR -- nouveau or nvidia blobs in play ? / what sort of time commit is > > > > yours showing (Ivor's last comment) > > > > > > > > @Quentin /IVOR does nomodeset getting a working desktop > > > > > > Not sure about blobs. Here's what is installed: > > > > > > akmod-nvidia-304xx.x86_64 304.125-1.fc21.1 > > > @System > > > kmod-nvidia-304xx-3.18.7-200.fc21.x86_64.x86_64 > > > 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 > > > > > > If you are referring to the gnome-shell CPU usage, here is the top of "top" > > > which shows high gnome-shell CPU usage in the 13 mins the system was up > > > after the nomodeset boot test: > > > > > > top - 08:46:30 up 13 min, 2 users, load average: 1.04, 1.18, 0.89 > > > Tasks: 204 total, 2 running, 202 sleeping, 0 stopped, 0 zombie > > > %Cpu(s): 56.0 us, 1.9 sy, 0.0 ni, 38.5 id, 3.4 wa, 0.0 hi, 0.1 si, 0.0 > > > st > > > KiB Mem : 3979952 total, 2275356 free, 421044 used, 1283552 buff/cache > > > KiB Swap: 4128764 total, 4128764 free, 0 used. 3324768 avail Mem > > > > > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > > 1936 gdm 20 0 395564 15088 13508 R 93.8 0.4 12:17.23 > > > gnome-shell > > > 3896 durham 20 0 146484 3820 3260 R 6.2 0.1 0:00.02 top > > > > > > Here's the nomodeset command line from the log which did not change the > > > black screen behaviour: > > > > > > [ 0.000000] Kernel command line: > > > BOOT_IMAGE=/vmlinuz-3.18.7-200.fc21.x86_64 > > > root=/dev/mapper/vg_clowder-lv_root ro > > > rd.md.uuid=d81bbcb8:a61669c8:c183b918:69fe889c LANG=en_US.UTF-8 SYSFONT=True > > > KEYTABLE=us rd.md.uuid=03bd61b0:56dd94bc:96264ee9:d4efd94d rd.luks=0 > > > rd.lvm.lv=vg_clowder/lv_swap rd.lvm.lv=vg_clowder/lv_root rd.dm=0 rhgb quiet > > > nomodeset > > > > > > Xorg.bin, gnome-session etc. are all running. <alt>F2 gets me to the text > > > login prompt. The first visual anomaly is that I don't even see the filling > > > tear-drop logo once gdm starts after the blue/white progress bar completes. > > > > Proprietary drivers are not supported by fedora, and this bug report is most > > likely unrelated to your problem, this seems to be specific to some asus > > notebooks. (And specification of the hardware that reported posted link to, > > doesn't have nvidia graphics in it) > > I will note that it fails with the nouveau driver too. Should I re-post as a > separate bug? Maybe you can first try asking on mailing lists, or IRC, it is easy to file a bug if needed later.
Already asked in the Fedora forum but I'll try re-phrasing the question there. There seem to be a number of complaints about blank/black screens with FC21 but no real clue to the potential problem(s).
@Corey > does nomodeset getting a working desktop Yes, the resolution is understandingly wrong, but it does display something (splash, gdm login screen) which is better than black. Now if we could get that at the right resolution that would be perfect.
(In reply to Quentin Brandon from comment #11) At a suggestion from the Fedora Forum I installed LXDE, stopped gdm and, if less prettily than with Gnome. The only thing I've found that doesn't so far is "logout" which seems like a no-op. This suggests that the problem is with gdm, at least as far as working with the Nvidia driver is concerned. Given that with nouveau I get a frozen screen with the last of the text boot displayed, I'm further ahead with the Nvidia driver now. Time to post a bug against Gnome?
(In reply to Ivor Durham from comment #12) > (In reply to Quentin Brandon from comment #11) > > At a suggestion from the Fedora Forum I installed LXDE, stopped gdm and, if > less prettily than with Gnome. The only thing I've found that doesn't so far > is "logout" which seems like a no-op. This suggests that the problem is with > gdm, at least as far as working with the Nvidia driver is concerned. Given > that with nouveau I get a frozen screen with the last of the text boot > displayed, I'm further ahead with the Nvidia driver now. Time to post a bug > against Gnome? This bug has been filed referring to specific hardware (Asus laptop with Intel graphics) which does not match your hardware. nomodeset did not have the same effect for your setup. This issue is not about gdm as the screen becomes black from the moment grub disappears (no splash screen, no progression bar, nothing) You now have to admit that your issue is unrelated to this bug report. The kernel bug #92241 referenced by bitlord seems to perfectly match what is going on here. As for your issue, you might get better visibility moving your activity to a more relevant thread.
(In reply to Quentin Brandon from comment #13) Can't access by 92241. New bug posted: https://bugzilla.redhat.com/show_bug.cgi?id=1198915
The proper link is: https://bugzilla.kernel.org/show_bug.cgi?id=92241 It is still unclear if any new patch may help as they have not been tested yet, but the issue is likely to be still present in kernel 4.0 3.18.8 still fails.
FYI Hacking the yum repo to use fc22 updates-testing, I could install kernel-4.0.0-0.rc4.git0.1.fc22 which fixes this issue. Too early to say if the whole system is stable enough, but I can already say that this comes with the benefit of having a functional trackpad (instead of the mouse simulation fallback mode of the 3.18.* kernel series)
The problem has gone away between kernels 3.18.9-200.fc21.x86_64 (boots to black screen) and 3.19.1-201.fc21.x86_64 (boots correctly)
Thank you. We are closing this out as the original reporter has confirmed the new kernel works.