Bug 970801 - plymouth-quit-wait.service fails, resulting in very long boot time.
Summary: plymouth-quit-wait.service fails, resulting in very long boot time.
Keywords:
Status: CLOSED DUPLICATE of bug 967521
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: 19
Hardware: Unspecified
OS: Unspecified
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-06-04 22:54 UTC by Rui Mota
Modified: 2023-06-01 06:31 UTC (History)
17 users (show)

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


Attachments (Terms of Use)

Description Rui Mota 2013-06-04 22:54:59 UTC
Description of problem:
During boot the boot seems to be complete but fedora splash image is still in the screen.
If I press scape I can see it the boot log that
plymouth-quit-wait.service failed to load and asking to run 
'systemctl status plymouth-quit-wait.service'

Then I just power off and boot again and if I'm lucky it will boot fine.

How reproducible:
Most of times at boot

Comment 1 Rui Mota 2013-06-05 08:33:38 UTC
Once it seem to hang before loading the Gnome Display Manager, just the splash was there, I had to reboot.

When it boots, I can see some services failing to load including firewalld.service
If I reboot, the service is ok now.
I don't like this inconsistency mostly when on critical services as a firewall.

Comment 2 Harald Hoyer 2013-06-06 11:15:39 UTC
check the logs:

# sudo journalctl

Comment 3 Randy 2013-08-03 14:24:33 UTC
Quick & easy fix:

yum -y erase plymouth

(since I can't find anything PRODUCTIVE that plymouth does, this seemed reasonable.)

Comment 4 Rui Mota 2013-08-03 21:26:03 UTC
And then I'll have an 80's style boot screen ?
No, thank you.

I would like to have a transparent gnome-terminal background, since that's no longer possible the solution is yum -y erase gnome-terminal ?
The flash plugin-container have issues in latest firefox, the solution is yum -y erase firefox ?

I think problems should be faced and fixed, not avoided.
It's i acceptable to replace plymouth with something better... remove it for a text boot is not an option.

Plymouth is not productive but it brings a cool boot screen.
If I remove most of non productive stuff from the system I would end in something like a fluxbox clean setup.
I like Fedora for the choice of software, security enhanced and for the gnome desktop.

But thank you anyway.

Let me share my workaround for this issue.
- ctrl + alt + f2
- login in text mode
- force a '$ init 3'
- and go back to '$ init 5'

The gdm is now visible and no need to reboot.

This is so ugly I know, I hope that will be fine someday after some fedora update.

Comment 5 Nelson Benitez 2013-08-13 17:45:45 UTC
I have the same problem, up-to-date fedora19 with pure gnome (not kde), and my boot time is delayed by waiting for the plymouth waiting service.

But in my case the plymouth screen is gone, so I don't need the gdm init workaround, just that my boot time is delayed by waiting for that service (my current boot time is 50sec so the time is not the problem, just that I want my fedora system to work right..)


[root@cartagena nelson]# systemctl status plymouth-quit-wait.service

plymouth-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 Tue 2013-08-13 19:16:47 CEST; 18min ago
 Main PID: 338
   CGroup: name=systemd:/system/plymouth-quit-wait.service



nelson@cartagena:~$ journalctl -b | grep plymouth

Aug 13 19:16:51 cartagena systemd[1]: plymouth-quit-wait.service operation timed out. Terminating.
Aug 13 19:16:51 cartagena systemd[1]: Unit plymouth-quit-wait.service entered failed state.

Comment 6 Mallikarjun 2013-08-14 18:54:05 UTC
Hi,

I am facing this problem very often now. The boot process stops at the plymouth error and does not proceed ahead.'

Here are the details-

[root@localhost sun]# systemctl status plymouth-quit-wait.service
plymouth-quit-wait.service - Wait for Plymouth Boot Screen to Quit
   Loaded: loaded (/usr/lib/systemd/system/plymouth-quit-wait.service; disabled)
   Active: inactive (dead) since Thu 2013-08-15 00:05:16 IST; 10min ago
  Process: 1430 ExecStart=/usr/bin/plymouth --wait (code=exited, status=0/SUCCESS)

[root@localhost sun]# journalctl | grep plymouth
Aug 15 00:03:34 localhost.localdomain systemd[1]: plymouth-quit-wait.service operation timed out. Terminating.
Aug 15 00:03:34 localhost.localdomain systemd[1]: Unit plymouth-quit-wait.service entered failed state.


The problem started since I updated my kernel to "kernel-3.10.4-300.fc19.x86_64" and the problem still persists in the latest "kernel-3.10.5-201.fc19.x86_64".

Please solve this problem or provide a solution soon.

Waiting for your reply.

Mallikarjun

Comment 7 Warren Lewis 2013-08-23 01:47:16 UTC
This is happening on my system too.  It acts like a race condition, sometimes GDM seems to come up fine, others it comes up after a long delay, and other times the Plymouth boot image stays on the screen and I have to switch to tty2 and do a telinit 3, then telinit 5. Restarting the graphical run level seems to work around the problem and I get a GDM login screen.

Comment 8 Mallikarjun 2013-08-23 06:34:47 UTC
Any updates on this bug??
Please solve this problem soon.

Comment 9 Scott Schmit 2013-08-23 21:39:22 UTC
(In reply to Warren Lewis from comment #7)
> This is happening on my system too.  It acts like a race condition,
> sometimes GDM seems to come up fine, others it comes up after a long delay,
> and other times the Plymouth boot image stays on the screen and I have to
> switch to tty2 and do a telinit 3, then telinit 5. Restarting the graphical
> run level seems to work around the problem and I get a GDM login screen.

"systemctl restart gdm" has worked for me

Comment 10 Mallikarjun 2013-08-25 15:52:20 UTC
Thanks :)

(In reply to Scott Schmit from comment #9)
> (In reply to Warren Lewis from comment #7)
> > This is happening on my system too.  It acts like a race condition,
> > sometimes GDM seems to come up fine, others it comes up after a long delay,
> > and other times the Plymouth boot image stays on the screen and I have to
> > switch to tty2 and do a telinit 3, then telinit 5. Restarting the graphical
> > run level seems to work around the problem and I get a GDM login screen.
> 
> "systemctl restart gdm" has worked for me

Comment 11 Kenny G 2013-08-27 14:44:11 UTC Comment hidden (spam)
Comment 12 Zbigniew Jędrzejewski-Szmek 2013-09-06 12:41:48 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.