Created attachment 774379 [details] one of these /var/log/gdm/(null).log's Description of problem: It has happened exactly 3 times, according to the log. Boot up just hangs at the progress screen for ever, in the middle, no disk activity, and not much cpu activity as far as I know - not responsive to CTRL-ALT-F2 ; it needs a hard power-reset to reboot, and fsck, etc. On closer examination, it is associated with 2 things: /var/log/messages: Jul 11 13:11:33 localhost systemd[1]: plymouth-quit-wait.service operation timed out. Terminating. Jul 11 13:11:33 localhost systemd[1]: Failed to start Wait for Plymouth Boot Screen to Quit. Jul 11 13:11:33 localhost systemd[1]: Unit plymouth-quit-wait.service entered failed state. a file called "/var/log/gdm/(null).log" or something similiar is created ( # ls -ltr /var/log/gdm/*null* -rw-r--r--. 1 root root 2129 Jul 6 02:58 /var/log/gdm/(null).log.2 -rw-r--r--. 1 root root 2138 Jul 11 12:46 /var/log/gdm/(null).log.1 -rw-r--r--. 1 root root 2138 Jul 11 13:11 /var/log/gdm/(null).log ) Version-Release number of selected component (if applicable): plymouth-0.8.9-0.2013.03.26.0.fc19.x86_64 systemd-204-9.fc19.x86_64 How reproducible: 3 times so far, since upgraded to f19 Steps to Reproduce: 1. just reboot 2. 3. Actual results: stuck in the progress plymouth screen. Expected results: Get to the log-in screen. Additional info:
Created attachment 774381 [details] /var/log/gdm/:0.log when x is working correctly. This is my 2nd most recent /var/log/gdm/:0.log - following a healthy boot-up session; for comparison. Please feel free to re-assign to plymouth. But I think systemd should try a bit harder to re-start plymouth if it is not working, really.
Reassigning to gdm, because: - when gdm is used, it is expected to be the thing that tells plymouth to quit. - its maintainers might know the cause of the oddly named logs. Meanwhile try if booting with "plymouth.enable=0" on the kernel command line makes a difference.
(In reply to Hin-Tak Leung from comment #1) > But I think systemd should try a bit harder to re-start plymouth if it is not > working, really. No. The problem is exactly the opposite. We need plymouth to *quit*. We do not want to restart it.
(In reply to Michal Schmidt from comment #3) > (In reply to Hin-Tak Leung from comment #1) > > But I think systemd should try a bit harder to re-start plymouth if it is not > > working, really. > > No. The problem is exactly the opposite. We need plymouth to *quit*. We do > not want to restart it. okay, obviously it is beyond my comprehension this whole business between systemd->plymouth->gdm->gnome-shell . It is just no good hanging in the middle of the boot sequence though, and rather hurts doing a reset and wait for fsck the whole thing. Perhaps I mean restarting gdm/X harder, as obviously X is mid-way and not going any further.
Any chance of somebody having any idea? It happened again (after not seeing it for a while). FWIW, it might be some sort of race condition. I sort of developed the habit of pressing ESC to switch back and forth to the text console (just to see some progress) and the hang hasn't happened for a while. It happens again when I am not doing that. (I started doing the ESC thing mostly see to the fsck progress, which was a consequence of hard reset following this problem...) It is another oddl named /var/log/gdm/(null).log, plus three lines in: Jul 31 17:42:24 localhost systemd[1]: plymouth-quit-wait.service operation timed out. Terminating. Jul 31 17:42:24 localhost systemd[1]: Failed to start Wait for Plymouth Boot Screen to Quit. Jul 31 17:42:24 localhost systemd[1]: Unit plymouth-quit-wait.service entered failed state. The last few things to start are (it is a laptop with a wifi-connection): NetworkManager, dhclient, chrony. Also the CMOS clock has somehow never been able to sync with network, so chrony always put the system clock back by about an hour when chrony finishes loading.
This is how I fixed it (finally): yum -y erase plymouth (Seemed reasonable, since I can't find anything productive that plymouth does.)
This appears to be a kernel problem. After updating to kernel 3.10.4, plymouth began failing for me in this manner. Booting with the previous kernel, kernel-3.9.9-302.fc19.x86_64, plymouth works fine. So, I think this is an issue with 3.10 kernels only. If I ESC out of plymouth during the boot, I can switch to an ALT-VT and capture this (the main screen remains frozen, and gdm fails to come up): lymouth-quit-wait.service - Wait for Plymouth Boot Screen to Quit Loaded: loaded (/usr/lib/systemd/system/plymouth-quit-wait.service; disabled) Active: failed (Result: timeout) since Sat 2013-08-03 11:30:35 EDT; 1min 46s ago Main PID: 2012 CGroup: name=systemd:/system/plymouth-quit-wait.service Aug 03 11:30:35 monster.email-scan.com systemd[1]: plymouth-quit-wait.service operation timed out. Terminating. Aug 03 11:30:35 monster.email-scan.com systemd[1]: Failed to start Wait for Plymouth Boot Screen to Quit. Aug 03 11:30:35 monster.email-scan.com systemd[1]: Unit plymouth-quit-wait.service entered failed state.
Comment on attachment 774379 [details] one of these /var/log/gdm/(null).log's make it plain text
(In reply to Sam Varshavchik from comment #7) ... > Booting with the previous kernel, kernel-3.9.9-302.fc19.x86_64, plymouth > works fine. So, I think this is an issue with 3.10 kernels only. That quite not the case - as is apparent looking at the first null.log's posted was from 3.9.9-301.fc19.x86_64. Also: # grep 'Current O' /var/log/gdm/*null* /var/log/gdm/(null).log:Current Operating System: Linux localhost.localdomain 3.10.3-300.fc19.x86_64 #1 SMP Fri Jul 26 00:00:58 UTC 2013 x86_64 /var/log/gdm/(null).log.1:Current Operating System: Linux localhost.localdomain 3.10.3-300.fc19.x86_64 #1 SMP Fri Jul 26 00:00:58 UTC 2013 x86_64 /var/log/gdm/(null).log.2:Current Operating System: Linux localhost.localdomain 3.10.3-300.fc19.x86_64 #1 SMP Fri Jul 26 00:00:58 UTC 2013 x86_64 /var/log/gdm/(null).log.3:Current Operating System: Linux localhost.localdomain 3.9.9-302.fc19.x86_64 #1 SMP Sat Jul 6 13:41:07 UTC 2013 x86_64 /var/log/gdm/(null).log.4:Current Operating System: Linux localhost.localdomain 3.9.9-301.fc19.x86_64 #1 SMP Thu Jul 4 15:10:36 UTC 2013 x86_64 So I have had it under 3 different kernels.
*** This bug has been marked as a duplicate of bug 967521 ***