Bug 741441 - kdm login screen is not displayed the first time at boot.
Summary: kdm login screen is not displayed the first time at boot.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kdebase-workspace
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ngo Than
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-26 20:03 UTC by Orion Poplawski
Modified: 2013-02-13 23:16 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-13 23:16:48 UTC


Attachments (Terms of Use)

Description Orion Poplawski 2011-09-26 20:03:45 UTC
Description of problem:

Fresh F16 install.  On boot I don't get a login prompt, just the background image.  If I kill kdm, a login prompt appears on restart.  It does not appear if I just kill kdm_greet.

Version-Release number of selected component (if applicable):
kdm-4.7.0-9.fc16.i686

How reproducible:
2 boots for 2 so far.

Comment 1 Orion Poplawski 2011-09-26 20:34:44 UTC
FWIW - when kdm restarts it runs X on vt2.

Comment 2 Orion Poplawski 2011-09-29 22:59:29 UTC
Apparently system dependent, don't see it on my VM.  Will start installing on other hardware and see how often I hit it.

Comment 3 Orion Poplawski 2011-10-20 16:49:42 UTC
So far only on 1 out of 5 installs.  I am using ldap with sssd on all machines.

Comment 4 Gary Tivey 2012-02-02 08:22:54 UTC
Getting similar behavior with normal KDM startup. Since fc16 Beta release.

during the 'plymouth' boot stage the screen has random color background

Boots to runlevel 5 with just the vern kdm background screen.

Ctl-alt-backspace restarts X and kdm then runs correctly



Hardware is Thinkpad T40 with ATI Mobility 7500

If you boot into runlevel 3 and manually execute prefdm.service all ok.

> systemctl start prefdm.service

Comment 5 Gary Tivey 2012-02-02 22:10:39 UTC
Reviewed the contents of /lib/systemd/system/prefdm.service and noticed that a cancellation of gettty@tty1 was specified in order to avoid a conflict with GDM which happens to use the same tty.

(from prefdm.service)

# On Fedora gdm/X11 is on tty1. We explicitly cancel the getty here to
# avoid any races around that.
Conflicts=getty@tty1.service plymouth-quit.service
After=getty@tty1.service plymouth-quit.service


After commenting both of these lines out, KDM starts and goes right to login.

# On Fedora gdm/X11 is on tty1. We explicitly cancel the getty here to
# avoid any races around that.
#Conflicts=getty@tty1.service plymouth-quit.service
#After=getty@tty1.service plymouth-quit.service

  

Perhaps an assumption was being made here that GDM would be used by default.
It is my understanding that KDM uses the next available tty, so it would seem that this precaution is not necessary on KDE installs.

Comment 6 Kevin Kofler 2012-02-02 22:15:47 UTC
This plymouth-quit.service stuff is very broken. Both GDM and KDM explicitly support quitting Plymouth themselves to allow for a flickerfree transition. These days we always get a flicker and now I know why!

Comment 7 Michal Schmidt 2012-02-02 23:56:48 UTC
Kevin,
The "Conflicts=plymouth-quit.service" is there specifically to make sure plymouth-quit.service is not run if prefdm.service is going to be started.
Would you elaborate what the problem is?

Comment 8 Kevin Kofler 2012-02-03 00:07:37 UTC
OK, so I guess I misunderstood what it does, but according to comment #5, it's clear that those lines are causing some kind of a problem, which is why I reassigned the bug to systemd. I don't know whether it's the getty@tty1.service conflict or the plymouth-quit.service one which is at fault there.

And it is also a fact that I haven't seen flickerfree transitions from Plymouth to KDM on my machines for a while, but to be honest, I don't know what component is at fault.

Sp please disregard my comment #6 and look at Gary Tivey's comment #5. :-)

Comment 9 Michal Schmidt 2012-02-03 01:39:54 UTC
> I don't know whether it's the getty@tty1.service conflict or
> the plymouth-quit.service one which is at fault there.

Gary, could you resolve this question for us?
Don't comment out the whole two lines, but see what happens if you delete only the references to one of the services. And then try it with the other one.

Comment 10 Gary Tivey 2012-02-03 02:39:53 UTC
Removed just the plymouth-quit.service statement in both lines of prefdm.service and kdm login screen appears normally.

Note: default them for plymouth is called 'charge'. 
Thought it might be useful to know how kdm would function with other plymouth themes . When using the non-graphic plymouth themes such as 'text' and 'details' the plymouth-quit.service statements in prefdm.service have no effect, and kdm login screen appears like it normally would. 

Michal, Hope this helps out.

Comment 11 Michal Schmidt 2012-02-03 10:34:20 UTC
(In reply to comment #10)
> Removed just the plymouth-quit.service statement in both lines of
> prefdm.service and kdm login screen appears normally.

So having systemd run plymouth-quit.service is actually helping kdm. Maybe kdm sometimes fails to quit plymouth by itself.

Let's check what plymouth thinks in both the working case and the broken case.
Please add "plymouth:debug" to your kernel command line parameters. Reboot and attach the resulting /var/log/plymouth-debug.log here.
Then revert prefdm.service to its original state and reboot again. Attach the new /var/log/plymouth-debug.log after the bug is reproduced.

Comment 12 Michal Schmidt 2012-02-03 10:40:51 UTC
While kdm appears stuck with the background screen, can you switch other VTs? Do you get login prompts there? If you can login there:
 - Does "systemctl list-jobs" show any jobs?
 - Does "systemctl --failed" show any failed units?

Comment 13 Gary Tivey 2012-02-03 15:59:02 UTC
For Comment #12

When kdm is stuck, a VT can be opened and login as root.

systemctl shown NO JOBS

systemctl --failed shows 'iscsid' service 

_______________________________________________________________

Form Comment #11

1.)added kernel command plymouth:debug to system running WITHOUT plymouth-quit.service and made a copy of /var/log/plymouth-debug.log.

2.)added kernel command plymouth:debug to reverted system running WITH plymouth-quit.service and kdm login started normally. Log copied. 

3.)rebooted system without the kernel plymouth:debug statement and kdm fails as initially reported with just the background screen and no login panel.

So it would seem that plymouth:debug is an influence here.

The plymouth:debug dumps are over 100k each. Even the diff is over 80k.

Still want me to post a copy Michal?

Comment 14 Michal Schmidt 2012-02-03 16:29:56 UTC
(In reply to comment #13)
> When kdm is stuck, a VT can be opened and login as root.
> systemctl shown NO JOBS
> systemctl --failed shows 'iscsid' service 

OK, this looks normal from systemd's point of view.

> ...
> So it would seem that plymouth:debug is an influence here.

Hm, a heisenbug.

> The plymouth:debug dumps are over 100k each. Even the diff is over 80k.
> Still want me to post a copy Michal?

100 KB is not a problem for a Bugzilla attachment. But if the bug could not
be reproduced with the logging enabled, the dumps will not be very useful.

It seems it's some race condition in plymouth or kdm.
A workaround is to quit plymouth before starting kdm. This of course goes against the goal of the smooth transition, but I for one wouldn't care.

This bug should be investigated from the kdm side. Maybe kdm writes some logs that can provide a hint. Or maybe you could attach to kdm with gdb while it's stuck and try to find out what it's waiting for. I don't know. Reassigning back to kdebase-workspace.

Comment 15 Gary Tivey 2012-02-03 16:42:00 UTC
Yes Michal, the dumps probably would not show what is hanging up the kdm login screen.  Will look at the kdm side of things now as suggested. 
Thanks for your help.

Comment 16 Kevin Kofler 2012-02-03 18:36:25 UTC
Yes, looking at the evidence, this seems to be KDM's fault. KDM logs things into /var/log/kdm.log.

Comment 17 Gary Tivey 2012-02-03 19:10:39 UTC
Hi Kevin ---

Ran both cases where one run had the plymouth-quit.service in prefedm.service
and the other without it.

In checking the /var/log/kdm.log there are no differences, they entries are identical. When the plymouth-quit.service is active, kdm halts prior to login screen.

Tried substituting plymouth-quit-wait.service for plymouth-quit.service and kdm will start to the login screen like normal. 
(Found plymouth-quit-wait.service by accident looking for plymouth logs)

  plymouth-quit-wait.service

[Unit]
Description=Wait for Plymouth Boot Screen to Quit
After=rc-local.service plymouth-start.service

[Service]
ExecStart=-/bin/plymouth --wait
Type=oneshot
TimeoutSec=20

 plymouth-quit.service

[Unit]
Description=Terminate Plymouth Boot Screen
After=rc-local.service plymouth-start.service

[Service]
ExecStart=-/bin/plymouth quit
Type=oneshot
TimeoutSec=20

The way it looks, is that one service waits for plymouth to quit on it's own, and the other forces plymouth to quit. Does plymouth really need to be involved beyond a boot to runlevel 3? (multi-usr) Or why is plymouth still engaged at runlevel 5.? (graphic-target)

Comment 18 Gary Tivey 2012-02-03 19:30:34 UTC
Related Systemd files

/lib/systemd/system/plymouth-quit-wait.service
/lib/systemd/system/multi-user.target.wants/plymouth-quit-wait.service

/lib/systemd/system/plymouth-quit.service
/lib/systemd/system/multi-user.target.wants/plymouth-quit.service

ls /lib/systemd/system/graphical.target.wants/
display-manager.service

ls /lib/systemd/system/multi-user.target.wants/
dbus.service                systemd-ask-password-wall.path
getty.target                systemd-logind.service
plymouth-quit.service       systemd-user-sessions.service
plymouth-quit-wait.service

Comment 19 Fedora End Of Life 2013-01-16 19:25:41 UTC
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 20 Fedora End Of Life 2013-02-13 23:16:52 UTC
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


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