plymouth-quit-wait.service runs into timeout

[wobo]

On a fresh installation of Cauldron i586 (via DVD):

First I did a minimal installation without X and without suggested packages. Boot after that works ok, networking came up, media were set. Logged in as root and installed 'task-kde4-minimal --no-suggests'. This was done without any error messages.

After this I rebooted and the start process stopped right after "Started Display Manager [OK] with the message:

Code: Select all

Failed to start Wait for Plymouth Boot Screen to Quit

I switched to a login on vt2, logged in as root and did:

Code: Select all

# systemctl status plymouth-quit-wait.service
plymouth-quit-wait.service - Wait for Plymouth Boot Screen to Quit
      Loaded: loaded (/lib/systemd/system/plymouth-quit-wait.service; static)
      Active: failed (Result: timeout) since Fri, 13 Apr 2012 14:47:08 +0200
    Main PID: 2042
      CGroup: name=systemd:/system/plymouth-quit-wait.service

This is reproducable and stops the system for good.
The issue is described in https://bugs.mageia.org/show_bug.cgi?id=5220 (1st item).

[wobo]

Starting in RL1 does not help, when the rescue shell is supposed to come up the process stops:

Code: Select all

Starting Rescue Shell...
Welcome to rescue mode. Use "systemctl default" or "^D" to activate default mode.
Failed to issue method call: Transaction is destructive

So I can't even do updates in case there has been an update for the issue.

[colin]

If plymouthd-quit-wait timesout and fails, it's simply because nothing else has quit plymouth for you.

It's a pseudo error in other words, a red-herring, and unrelated to whatever problem you currently have.

What is far more interesting is the output from systemctl status prefdm.service

[martinw]

@Colin, I explored this a bit with wobo in https://bugs.mageia.org/show_bug.cgi?id=5220, as I wondered whether it was another manifestation of the circular dependency problem. Although my conclusion was that wobo's problem lies elsewhere, there are jobs being deleted due to circular dependencies:

Code: Select all

[    5.017795] systemd[1]: Found ordering cycle on basic.target/start
[    5.021320] systemd[1]: Walked on cycle path to sockets.target/start
[    5.024799] systemd[1]: Walked on cycle path to syslog.socket/start
[    5.028209] systemd[1]: Walked on cycle path to basic.target/start
[    5.031579] systemd[1]: Breaking ordering cycle by deleting job syslog.socket/start
[    5.035132] systemd[1]: Looking at job getty@tty1.service/stop conflicted_by=yes
[    5.035146] systemd[1]: Looking at job getty@tty1.service/start conflicted_by=no
[    5.035159] systemd[1]: Fixing conflicting jobs by deleting job getty@tty1.service/start
[    5.035185] systemd[1]: Looking at job prefdm.service/start conflicted_by=no
[    5.035197] systemd[1]: Looking at job prefdm.service/stop conflicted_by=no
[    5.035208] systemd[1]: Fixing conflicting jobs by deleting job prefdm.service/stop
[    5.035229] systemd[1]: Looking at job plymouth-quit.service/stop conflicted_by=yes
[    5.035241] systemd[1]: Looking at job plymouth-quit.service/start conflicted_by=no
[    5.035253] systemd[1]: Fixing conflicting jobs by deleting job plymouth-quit.service/start


I checked on my machine, and found the same messages. I don't think any SysV init scripts are involved here.

[wobo]

Pls see the bug report.

I succeeded to solve the issue of the X server not starting (because X was not configured yet), while the issue with the hanging plymouth-quit-wait.service is still there.

What is far more interesting is the output from systemctl status prefdm.service

Code: Select all

# systemctl status prefdm.service
prefdm.servive - Display Manager
   Loaded: loaded (/lib/systemd/system/prefdm.service; static)
   Active: inactive (dead)
   CGroup: name=systemd:/system/predm.service


[martinw]

@wobo, what happens if you enter

Code: Select all

systemctl start prefdm.service


when logged in as root on vt2?

[wobo]

Well, here comes a long story:

This morning everything was like described before
- system booting until the described error message
- logging in as user in vt2 and starting 'startx' started the KDE system.

Tonight I started the machine again and it booted through to a text prompt on vt1. Logged in as user, did startx and KDE came up fine!
Now I looked at /etc/inittab - it was set to boot into RL3, which I never did. I did no updates or any other changes either between this morning and tonight, so I wonder why it boots now without error message.

Now I changed RL to 5 in /etc/inittab but on reboot I landed in RL3 as before. Looking at /var/log/kdm.log shows errors about "D-Bus call failed: "Not connected to D-Bus server"" But when I do startx KDE comes up ok.

To answer your question:
'systemctl start prefdm.service' as root starts KDM ok, now on vt1.

[martinw]

I'm always worried when bugs fix themselves - it usually means they are just hiding!

OK, if you can start prefdm.service manually and have KDM working, there can't be any vital packages missing now. So if it's failing to start automatically when the machine boots, that suggests something wrong with the order in which services are being started. I guess we need to visit the system logs again, after booting with the systemd debug kernel options, to see if we can figure out where the problem is.

[wobo]

Yes, probably.
But I'm just waiting for Beta3 to do a fresh installation and then investigate from there.

[martinw]

Looks like the same bug here: http://www.mageia.org/pipermail/mageia-dev/2012-April/014369.html

So unlikely to be fixed in beta3, but Colin is working on it.

[Northsoft]

Hello all, I have the same issue, I'm just able to login at VT2 as user and do startx
How should I set up KDM autostart?
Mageia 2 [Linux localhost 3.3.8-desktop-2.mga2 #1 SMP Mon Jul 30 21:35:06 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux]

[pradhanphy]

I had the same problem.
I Guess drakrpm-update hangs while doing the update .
It mess up everything.
All i did press "Ctrl + Alt + F2" login as root. Enter "dracut -f " and rebooted .
Everything is working fine now.