Bug 987242 - plymouth-quit-wait.service fails, resulting in very long boot time.
Summary: plymouth-quit-wait.service fails, resulting in very long boot time.
Status: CLOSED DUPLICATE of bug 1006386
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: 19
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-07-23 04:16 UTC by Heiko Adams
Modified: 2014-01-28 10:43 UTC (History)
27 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 921785
Last Closed: 2014-01-28 10:43:34 UTC
Type: Bug

Attachments (Terms of Use)

Description Heiko Adams 2013-07-23 04:16:33 UTC
+++ This bug was initially created as a clone of Bug #921785 +++

Description of problem:
It takes quite a long time for my otherwise quite capable laptop to boot up. After following boot process in text mode i noticed that boot process hangs for some 15 seconds after WPA Supplicant daemon start and throws "Failed to start Wait for Plymouth Boot Screen to Quit." message.

Version-Release number of selected component (if applicable):

How reproducible:
every boot time.

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Heiko Adams 2013-07-23 04:32:49 UTC
In my case gdm doesn't show up even after several minutes of waiting. The only way to have a gdm instance is to switch to tty2, disable gdm.service, enable lightdm.service and reboot. After reboot switch to tty2 again, disable lightdm, enable gdm and reboot. After this reboot gdm comes up for one time.

Comment 2 Oliver Paukstadt 2013-07-24 19:59:25 UTC
Had the same effect here.
gdm did not start any more.

Set selinux to permissive and everything is fine now (except that selinux is permissive ;-))

Comment 3 Mikhail Koshelev 2013-07-26 04:16:11 UTC
Similar symptoms, happens quite often on my notebook. Systemd login sequence shows "Starting target Graphical Interface" IIRC, but no actual gdm screen comes up.
gdm and Xorg logs in /var/log/ aren't updated, though ps shows there's a gdm process in memory.

The workaround in my case is to login via text console on tty2 and kill gdm process - it then respawns and login screen comes up on tty1.

Comment 4 Till Maas 2013-07-26 07:51:19 UTC
On a different system removing /var/log/journal helped to get it booting properly again, see bug 988231.

Comment 5 Heiko Adams 2013-07-28 08:22:47 UTC
I can confirm that clearing /var/log/journal is a suitable workaround for this problem.

Comment 6 Karel Volný 2014-01-28 10:43:34 UTC
I believe this is just another occurence of the same issue that was finally taken care of (I'm hesitant to say it was "resolved" or "fixed") through bug #1006386, so closing as duplicate

(note that a few other problems were revealed and fixed along, so it doesn't need to be 100% accurate ...)

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

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