Description of problem: ======================= Today, performed am upgrade using yum. yum.log says: Jun 14 16:06:23 Updated: systemd-libs-208-17.fc20.x86_64 Jun 14 16:06:25 Updated: systemd-208-17.fc20.x86_64 Jun 14 16:06:33 Installed: kernel-3.14.7-200.fc20.x86_64 Jun 14 16:06:33 Updated: nspr-4.10.6-1.fc20.x86_64 Jun 14 16:06:40 Updated: firefox-30.0-4.fc20.x86_64 Jun 14 16:06:42 Installed: kernel-modules-extra-3.14.7-200.fc20.x86_64 Jun 14 16:06:42 Updated: libgudev1-208-17.fc20.x86_64 Jun 14 16:06:42 Updated: satyr-0.14-1.fc20.x86_64 Jun 14 16:06:42 Updated: spice-server-0.12.5-2.fc20.x86_64 Jun 14 16:06:43 Updated: kernel-headers-3.14.7-200.fc20.x86_64 Jun 14 16:06:44 Updated: fpaste-0.3.7.3-1.fc20.noarch Jun 14 16:06:44 Updated: systemd-libs-208-17.fc20.i686 Reboot after this yields problems: 1) The boot menu allowing you to select the kernel comes up. 2) Wait until boot continues 3) The screen becomes black; it may or may not display the message "Booting Fedora" etc. at the top level. 4) It then waits indefinitely with a non-blinking cursor. 5) CTRL-ALT-DEL may get it out of its funk. X) One instance of successful boot observed though. Weird. Boot into rescue mode succeeds (currently writing from there) This may be due to a hardware problem appaearing at the same times as the update, but this is unlikely. Hardware is an oldish Amilo Xi3650 with an SSD. Version-Release number of selected component (if applicable): ------------------------------------------------------------- kernel-3.14.7-200.fc20.x86_64 How reproducible: ----------------- Very much consistently Will now run memtest,,,,
Pretty sure it's it's the graphical startup (i.e. "plymouth", right) Because the SSD is encrypted and what usually comes up after "Booting Fedora" is the screen with the slowly filling Fedora logo, and the you get asked for the passphrase to unlock the disk. In this situation, you just look into the equivalent of the Core of the Event Horizon, but typing the passphrase blindly actually makes the system boot.
Component is plymouth-0.8.9-3.2013.08.14.fc20.x86_64
Several boot attempts reveal that kernel 3.14.7-200 -- consistently no graphical screen kernel 3.14.6-200 -- consistently no graphical screen kernel 3.14.5-200 -- conistently works I should have noticed 3.14.6-200 not working earlier though. Excpet if I didn't boot the machine after update. Which is possible.
You should also be able to hit ESC during boot to switch to the console prompt for the password.
> You should also be able to hit ESC during boot to switch to the console prompt for the password. Indeed, I didn't know about that. Hitting ESC shows the passphrase entry prompt text (in Linux framebuffer mode, right?)
No solution yet (kernel 3.14.9). However I found that if one waits a few minutes, plymouth gives up and drops to text mode (a timeout?), at which point the passphrase prompt for the LUKS-encrypted partition becomes visible. --> See dmesg.txt. Note that the laptop (Fujitsu-Siemens AMILO Xi 3650) here has a mix of: ---- 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) 01:00.0 VGA compatible controller: NVIDIA Corporation G96M [GeForce 9600M GT] (rev a1) ---- Possibly similar (not studied in detail yet - but I my case it is NOT the brightness; it's just that no text is displayed) ---- https://bugzilla.redhat.com/show_bug.cgi?id=1095601 https://ask.fedoraproject.org/en/question/44120/black-screen-on-fedora-20-right-after-grub/ https://ask.fedoraproject.org/en/question/38644/black-screen-after-the-system-update-of-fedora-20/ https://ask.fedoraproject.org/en/question/29186/black-screen-after-upgrade-to-kernel-310/ ----
Created attachment 913844 [details] dmesg dump
Okay, today it worked. That's interesting. Yesterday's updates and installs do NOT show anything that should have affected graphical boot: Jul 16 10:40:44 Updated: 1:mariadb-libs-5.5.38-3.fc20.x86_64 Jul 16 10:40:47 Updated: 1:mariadb-5.5.38-3.fc20.x86_64 Jul 16 10:40:50 Updated: 1:mariadb-server-5.5.38-3.fc20.x86_64 Jul 16 10:40:51 Updated: libXfont-1.4.8-1.fc20.x86_64 Jul 16 10:40:52 Updated: 1:mariadb-embedded-5.5.38-3.fc20.x86_64 Jul 16 11:13:00 Installed: qpdf-5.1.1-1.fc20.x86_64 Jul 16 17:00:47 Installed: ImageMagick-libs-6.8.6.3-4.fc20.x86_64 Jul 16 17:00:48 Installed: python-pillow-2.2.1-4.fc20.x86_64 Jul 16 17:00:48 Installed: perl-XML-RegExp-0.04-4.fc20.noarch Jul 16 17:00:48 Installed: perl-XML-DOM-1.44-20.fc20.noarch Jul 16 17:00:49 Installed: python-reportlab-3.1.8-1.fc20.x86_64 Jul 16 17:00:49 Installed: ImageMagick-6.8.6.3-4.fc20.x86_64 Jul 16 17:00:49 Installed: ImageMagick-c++-6.8.6.3-4.fc20.x86_64 Jul 16 17:00:50 Installed: potrace-1.11-3.fc20.x86_64 Jul 16 17:00:50 Installed: uniconvertor-2.0-0.4.svn362.fc20.x86_64 Jul 16 17:00:51 Installed: gtkspell-2.0.16-7.fc20.x86_64 Jul 16 17:00:51 Installed: perl-Parse-Yapp-1.05-53.fc20.noarch Jul 16 17:00:52 Installed: perl-Date-Manip-6.45-1.fc20.noarch Jul 16 17:00:52 Installed: perl-XML-XQL-0.68-22.fc20.noarch Jul 16 17:00:53 Installed: gc-7.2d-3.fc20.x86_64 Jul 16 17:00:53 Installed: python-backports-1.0-3.fc20.x86_64 Jul 16 17:00:53 Installed: python-backports-ssl_match_hostname-3.4.0.2-1.fc20.noarch Jul 16 17:00:53 Installed: python-setuptools-1.4.2-1.fc20.noarch Jul 16 17:00:54 Installed: python-nose-1.3.0-1.fc20.noarch Jul 16 17:00:56 Installed: 1:numpy-1.8.0-4.fc20.x86_64 Jul 16 17:00:56 Installed: libbluray-0.6.0-1.fc20.x86_64 Jul 16 17:00:57 Installed: gvfs-1.18.3-2.fc20.x86_64 Jul 16 17:01:01 Installed: gnome-vfs2-2.24.4-14.fc20.x86_64 Jul 16 17:01:04 Installed: inkscape-0.48.4-10.fc20.x86_64
No, it was arbitrary. A reboot brought the problem back.
Same problem here. I have tried to enter the passphrase at the blank screen but no luck. I am attempting this on a live image. The image is created using sudo livecd-iso-to-disk --format --efi --home-size-mb 1000 Fedora-Live-KDE-x86_64-21-5.iso /dev/sdb1 I went back to fedora 20 and that works as expected.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 '20'. 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 20 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 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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.