Bug 985038

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 ***