Bug 996370

Hi Bruno,
could you please post the journal output from the boot and /var/log/kdm.log if it's present and containing any information from the time when this behavior occurs?
Do you experience any other unusual behavior or are running a nonstandard setup worth mentioning?
Thank you.

Created attachment 786208 [details]
kdm log file

This looks to be from when I rebooted last night.

I'll look at getting the journal output.

I'm running network instead of NetworkManager.

I am seeing a problem with the plymouth-quit-wait.service.

I have a pretty old video card (rv280 based ATI 9200).

Upon further checking the kdm log was from a restart of the kdm service, not a boot. I'll need to reboot to get one from a failed attempt and I can't do that until I'm back home again tonight. The journal output might be more useful. I should have that soon.

Created attachment 786209 [details]
journalctl -b output

It looks like kdm is checking for plymouth to end so this might be related to the plymouth bug 967521 (there are some other bugs that look like duplicates of that one).

It seems KDM isn't started at all on bootup. Are you sure the service is enabled? 
 # systemctl status kdm.service | grep Loaded
    Loaded: loaded (/usr/lib/systemd/system/kdm.service; enabled)
Yes, I know you wrote it happens half of the time but I'd like to be sure anyway.

[root@bruno bruno]# systemctl status kdm.service
kdm.service - The KDE login manager
   Loaded: loaded (/usr/lib/systemd/system/kdm.service; enabled)
   Active: active (running) since Wed 2013-08-14 07:48:56 CDT; 4min 15s ago
 Main PID: 8625 (kdm)
   CGroup: /system.slice/kdm.service
           ├─8625 /usr/bin/kdm vt1
           └─8630 /usr/bin/X :0 vt2 -background none -nolisten tcp -seat seat...

Aug 14 07:48:56 bruno.wolff.to systemd[1]: Started The KDE login manager.
Aug 14 07:48:57 bruno.wolff.to kdm[8625]: plymouth --ping -> 0
Aug 14 07:48:57 bruno.wolff.to kdm[8625]: plymouth is running ...
Aug 14 07:48:57 bruno.wolff.to kdm[8625]: plymouth deactivate -> 0
Aug 14 07:48:57 bruno.wolff.to kdm[8625]: plymouth --has-active-vt -> 0
Aug 14 07:48:57 bruno.wolff.to kdm[8625]: plymouth should quit when server s...s
Aug 14 07:48:57 bruno.wolff.to kdm[8625]: plymouth is active on VT 2, reusin...0
Aug 14 07:49:02 bruno.wolff.to kdm[8625]: Quitting Plymouth with transition
Aug 14 07:49:02 bruno.wolff.to kdm[8625]: plymouth --wait quit --retain-spla...0
Aug 14 07:49:02 bruno.wolff.to kdm[8625]: Is Plymouth still running? no

Created attachment 786530 [details]
kdm log from failed start at boot

After booting there was a kdm log from this morning, so it looks like kdm is trying to get started, but fails. I copied this one over before restarting kdm (which got it working).

Yes, I see it now, it's running before reaching the multi-user target, journal just doesn't contain a message about its start. Seems it could be related to the plymouth bug... Do you have any special settings regarding this, please? By which I mean if you turned off some of the plymouth services or disabled plymouth in kernel commandline.
Thank you.

I do a non-graphical boot. I have removed a couple of kernel parameters to do that.
Here is the kernel linefrom grub.conf:
kernel /vmlinuz-3.11.0-0.rc6.git0.2.fc20.i686+PAE ro root=/dev/mapper/luks-9a976
b86-8aaa-40d9-8039-89d710eac5c9 SYSFONT=latarcyrheb-sun16 LANG=en_DK.UTF-8 KEYTA
BLE=us radeon.agpmode=-1 noreplace-smp slub_debug=-

I haven't had kdm start normally in quite a while now. Possibly the successes I was sometimes seeing were with older initramfs images I had been trying when I started having the problem.

Tonight when I rebooted kdm came up normally (and also sound which is another bug I had filed). The plymouth-quit-wait.service didn't hang. In fact I can't find the string plymouth in dmesg output. So it seems likely the issue with plymouth was related to my kdm and audio problems (at least as a trigger).
I don't know why I am not seeing the plymouth hang now, so I don't know if things are really fixed or if I got lucky.

Apparently I just got lucky. plymouth-quit-wait.service failed and so did kdm.

This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20

While using kdm as display manager, I had seen plymouth-quit-wait.service fail just before the kdm.service and they seem unrelated. [P]lymouth-quit-wait.service failure is because the initramfs is configured with plymouth while the other systemd plymouth services are disabled. [K]dm is started normally by kdm.service and is running but the X server that it spawns fails. See /var/log/kdm.log and /var/log/Xorg.0.log for X server termination. [K]dm does not seem to notice, and this may or may not be because of the way it is invoked in kdm.service. I have not had more time to troubleshoot this problem.

Just a note, I was havning an issue with Failed to Start Wait for Plymouth Boot screen to Quit error message and not booting properly and finally not booting at all today.  Followed the suggesting from bug 987242 to remove /var/log/journal and tried to reboot.  System now working as expected.

Don't know if that will help or not.  Machine boots much faster now.

Full F19 KDE with all updates as of today.

Hey, sometimes this problem also affects me:

Problem: KDM doesn't show up and either the fedora loading logo keeps visible (completely loaded), or I get some text output, which I will add as attachment in my next comment.
In the first case (fedora loading logo), I can't go to other tty's, but I'm able to do a "normal" shutdown by pressing my computer's power button once.
In the second case (text output), I can go to other tty's and run "service kdm stop && service kdm start" to let KDM show up. When I execute "systemctl status plymouth-quit-wait.service", I get the following output:

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 Wed 2013-10-09 10:14:06 CEST; 2min 37s ago
 Main PID: 588
   CGroup: name=systemd:/system/plymouth-quit-wait.service

How reproducible: seems to be rather random, failing ~1 on 5 boots.

I think this bug showed up after installing an incremental update of "kde-workspace-libs, kgreeter-plugins, kcm_colors, kdm-themes, kde-wallpapers, kde-workspace, libkworkspace, plasma-scriptengine-python, kdm".

Yum Info of these packages:

Installed Packages
Name        : kcm_colors
Arch        : x86_64
Version     : 4.11.1
Release     : 3.fc19

Name        : kde-wallpapers
Arch        : noarch
Version     : 4.11.1
Release     : 1.fc19

Name        : kde-workspace
Arch        : x86_64
Version     : 4.11.1
Release     : 3.fc19                   

Name        : kde-workspace-libs
Arch        : x86_64
Version     : 4.11.1
Release     : 3.fc19

Name        : kdm
Arch        : x86_64
Version     : 4.11.1
Release     : 3.fc19

Name        : kdm-themes
Arch        : noarch
Version     : 4.11.1
Release     : 3.fc19

Name        : kgreeter-plugins
Arch        : x86_64
Version     : 4.11.1
Release     : 3.fc19

Name        : libkworkspace
Arch        : x86_64
Version     : 4.11.1
Release     : 3.fc19

Name        : plasma-scriptengine-python
Arch        : x86_64
Version     : 4.11.1
Release     : 3.fc19

Created attachment 809782 [details]
KDM doesn't show up, only text output does

Printscreen of text output on boot, instead of showing up KDM.

does clearing systemd journal help?

rm -rf /var/log/journal/* ; reboot

Maybe right after doing that, yes, but after some reboots the issue will eventually show up again. And when it shows up, recall that it will only show up ~1 on 5 boots.

On the laptop that I removed the /var/log/journal/, the computer has been rebooted many times with no issues.  Much more than 5 reboots and still no issues with booting related to this but.  Seems to fix most of the strange issues on the laptop.

Problem persists when installing the new incremental update:

Yum Info of these packages:

Installed Packages
Name        : kcm_colors
Arch        : x86_64
Version     : 4.11.2
Release     : 1.fc19

Name        : kde-wallpapers
Arch        : noarch
Version     : 4.11.2
Release     : 1.fc19

Name        : kde-workspace
Arch        : x86_64
Version     : 4.11.2
Release     : 1.fc19

Name        : kde-workspace-libs                                                                                                                          
Arch        : x86_64                                                                                                                                      
Version     : 4.11.2                                                                                                                                      
Release     : 1.fc19

Name        : kdm
Arch        : x86_64
Version     : 4.11.2
Release     : 1.fc19

Name        : kdm-themes
Arch        : noarch
Version     : 4.11.2
Release     : 1.fc19

Name        : kgreeter-plugins
Arch        : x86_64
Version     : 4.11.2
Release     : 1.fc19

Name        : libkworkspace
Arch        : x86_64
Version     : 4.11.2
Release     : 1.fc19

Name        : plasma-scriptengine-python
Arch        : x86_64
Version     : 4.11.2
Release     : 1.fc19

Created attachment 810938 [details]
kdm log file 2

Re: comment #19

Elias, to fully test things, (temporarily) set in /etc/systemd/journald.conf :
Storage=volatile

if you can still reproduce the kdm failure after that, then the journal is indeed not the only culprit here.

OK, I'll try it and post results when I've got some time.

(In reply to Rex Dieter from comment #23)
> Re: comment #19
> 
> Elias, to fully test things, (temporarily) set in /etc/systemd/journald.conf
> :
> Storage=volatile
> 
> if you can still reproduce the kdm failure after that, then the journal is
> indeed not the only culprit here.

Until now, it seems to be working. I booted about 5 times.

I'll report when there's something wrong, or when I reach 15+ successful reboots.

(In reply to Rex Dieter from comment #23)(In reply to Rex Dieter from comment #23)
> Re: comment #19
> 
> Elias, to fully test things, (temporarily) set in /etc/systemd/journald.conf
> :
> Storage=volatile
> 
> if you can still reproduce the kdm failure after that, then the journal is
> indeed not the only culprit here.

All right, so I passed reach 15+ successful reboots.
So I think you're right, the journal IS the only culprit here.

OK, let's dup this against the existing journald one, bug #967521

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