(In reply to comment #0)
> Description of problem:
> after reboot (not the first one) of a newly installed cauldron system (on a
> Lenovo T420) several services fail:

Same situation after new installed cauldron on a Lenovo S10e netbook (i586): 
> 
> # 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 Tue, 03 Apr 2012 16:50:35 +0100;
> 9h ago
>     Main PID: 2384
>       CGroup: name=systemd:/system/plymouth-quit-wait.service

This is reproduceable and stops the boot process for good. For me this is a release-critical issue.

CC: (none) => molch.b

Adding to the last sentence of comment #1 :

I can't even do updates or corrections, the system is hosed!

Booting failsafe (RL1) ends in 
"Starting Rescue Shell...
Welcome to rescue mode. Use "systemctl default" or "^D" to activate default mode.
Failed to issue method call: Transaction is destructive "

Some more info:
The installation was done via i586 DVD, first a minimal system which booted fine. Network came up, media were set. 
Then I did 'urpmi task-kde4-minimal --no suggests' which worked fine. After that I did nothing else than reboot, which resulted in the plymouth-quit-wait timeout.

I wonder if this is related to bug #5262. If you boot with the extra boot options

  systemd.log_level=debug systemd.log_target=kmsg

then log in as root on a virtual terminal and inspect /var/log/dmesg, do you see any messages about services being deleted?

CC: (none) => mageia

Well, I added the extra boot options and let the system start run until it ended at the same point. Then looked at dmesg but could not find any more info about plymouth-quit-wait.service. It is started, then received timeout. Failed.

Just to check - you did look in /var/log/dmesg, not run the 'dmesg' command (I always assumed these were the same, but they aren't...).

It might be worth attaching a copy of /var/log/dmesg, just in case it gives anyone some clues as to what's wrong.

Created attachment 1985 [details]
contents of /var/log/dmesg

Ah yes, the interesting lines are:

[    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

No, comparing this to a working system, these messages appear to be normal. So this looks to be different to bug #5262.

If you attach the output of the 'dmesg' command (saved to a file) and a copy of /var/log/syslog, I'll take a look to see if I can spot anything else - but I'm not an expert on this.

Neither am I. What makes me nervous that this release critical bug has been open for 10 days, we are at Beta3, but it has not been attached to anybody by now.  

Ok, could you give me a hint how I save the output of dmesg into a file?

At a terminal prompt, type

  dmesg > output-file

and the output will be saved in output-file (substitute whatever you like for output-file).

Duh! I did that this morning because I always do it like that, but I received a failure message, so I thought dmesg needs a different syntax.

Ok, now it worked :)

Created attachment 1986 [details]
Saved output of dmesg as of 14 Apr 2012 08:04 GMT +0200

Created attachment 1987 [details]
/var/log/syslog starting at 14 Apr 2012 08:04 GMT +0200

OK, in syslog we have:

Apr 14 04:17:21 localhost kdm[2077]: X server died during startup
Apr 14 04:17:21 localhost kdm[2077]: X server for display :0 cannot be started, session disabled

I'm fairly sure this is a different problem to the systemd service failures (some of which, like the failure to load Intel/AMD microcode, are probably harmless), so rather than hijack this bug report, can I suggest you open a new bug and attach /var/log/Xorg.0.log and also any logs you can find for kdm (for gdm, there is a directory /var/log/gdm - so try looking for /var/log/kdm). From your post in the forum, I guess this problem is due to you trying out a minimal install, and it will probably turn out to be a missing dependency that means a vital package hasn't been installed. Put me on the cc list, and I'll take a look.

Hmm, I'm not sure about your assessment. I'll check Xorg.0.log.

There I see that at the end the log shows failures to load the modules intel, vesa, fdev, consequently showing "No drivers available" and the well known "Fatal server error: no screens found"

kdm log shows exactly the same ("failed to load module" for all 3 modules).

But usually in this case you are dropped to a text login, not just hanging in the air.

Anyway, I'll open another bug report.

My guess is that you aren't dropped to a text login because systemd has deleted the necessary job:

[    5.035159] systemd[1]: Fixing conflicting jobs by deleting job
getty@tty1.service/start

Colin has responded to your post in the forum - perhaps he will be able to shed more light on this.

(In reply to comment #15)

> Anyway, I'll open another bug report.

No, I did not because I found out that it has nothing to do with X.

I booted, system ended as reported with the failure message.
 - logged in as root on tty2
 - started XFdrake, several packages were installed and X was configured
 - rebooted -> system hangs on failure message as reported
 - logged in as user on tty2 and did 'startx' -> X and KDE came up just fine!

So, leaving 2 questions open:

The bug as reported about plymouth-wait-quit.service is still open.

Why did task-kd4-minimal not install the drivers for X? This is certainly a
topic for another bug report. But if the system would drop me at a prompt
because X was not yet configured, no problem. I could live with that.

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

Hi,
user gribodo (from mageiaonline.it) is experiencing this issue after Mageia 2 installation.
I'm helping him following this bug report.

The reference to the italian discussion:
http://www.mageiaonline.it/bb/viewtopic.php?f=26&t=38

Let me know which kind of data I can provide to be of help.

Regards,
matteo

CC: (none) => pasotti.matteo

@Colin : can you shine a light on this matter. 

Roelof

And can anyone confirm this bug on Mageia2 or Mageia 3 ?

Roelof

Chances are this problem stems from something in the boot sequence causing a breakage resulting in one or more jobs being deleted. In my experience, the job to start prefdm.service is typically one that gets ejected.

This can happen when third party non-LSB initscripts are used.

In order to tell if the problem is that, please do a fresh boot, switch to tty2 and do "systemctl show prefdm.service | grep ^Active".

If it says: 
ActiveEnterTimestampMonotonic=0

in there then the job hasn't even tried to start, but the conflicts with a getty on tty1 has been honoured, meaning that the unit has been parsed but subsequently ejected from the transaction due to a conflict.

The next step would be narrowing down what job caused this. Try checking in /etc/init.d folder and looking for anything not provided by a package (rpm -qf /etc/init.d/*) and also anything provided by any unofficial packages (e.g. from vmware, cisco etc. etc.). If you find such files in there, add proper LSB headers to them to hopefully fix the job ejection.

I have a similar problem here:
https://bugs.mageia.org/show_bug.cgi?id=6719

I dont have any non boot problem, only it stacks for a while in "Failed to start Wait for Plymouth Boot Screen to Quit"

CC: (none) => dglent

The microcode problem is fixed by installing the package:
microcode-0.20131009-3.mga4.nonfree

Q1: does it matter if this is omitted?
Q2: should this be installed by default? It's not free software, but I think most of the arguments against non-free software don't apply to this package.

CC: (none) => mageia

Remove needinfo as all info given. Appears to be fixed by installing microcode, so closed

Keywords: NEEDINFO => (none)
Status: NEW => RESOLVED
CC: (none) => nic
Resolution: (none) => FIXED