Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 985038 - boot up hangs. plymouth-quit-wait.service operation timed out. Terminating.
Summary: boot up hangs. plymouth-quit-wait.service operation timed out. Terminating.
Keywords:
Status: CLOSED DUPLICATE of bug 967521
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: 19
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-16 15:45 UTC by Hin-Tak Leung
Modified: 2013-09-06 12:42 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-09-06 12:42:40 UTC


Attachments (Terms of Use)
one of these /var/log/gdm/(null).log's (deleted)
2013-07-16 15:45 UTC, Hin-Tak Leung
no flags Details
/var/log/gdm/:0.log when x is working correctly. (deleted)
2013-07-16 15:51 UTC, Hin-Tak Leung
no flags Details

Description Hin-Tak Leung 2013-07-16 15:45:46 UTC
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:

Comment 1 Hin-Tak Leung 2013-07-16 15:51:36 UTC
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.

Comment 2 Michal Schmidt 2013-07-16 15:53:29 UTC
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.

Comment 3 Michal Schmidt 2013-07-16 15:55:35 UTC
(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.

Comment 4 Hin-Tak Leung 2013-07-16 16:46:33 UTC
(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.

Comment 5 Hin-Tak Leung 2013-07-31 21:05:35 UTC
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.

Comment 6 Randy 2013-08-03 14:27:43 UTC
This is how I fixed it (finally):

yum -y erase plymouth

(Seemed reasonable, since I can't find anything productive that plymouth does.)

Comment 7 Sam Varshavchik 2013-08-03 15:43:30 UTC
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 8 Hin-Tak Leung 2013-08-09 03:09:13 UTC
Comment on attachment 774379 [details]
one of these /var/log/gdm/(null).log's

make it plain text

Comment 9 Hin-Tak Leung 2013-08-09 03:12:34 UTC
(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.

Comment 10 Zbigniew Jędrzejewski-Szmek 2013-09-06 12:42:40 UTC

*** This bug has been marked as a duplicate of bug 967521 ***


Note You need to log in before you can comment on or make changes to this bug.