Bug 736912 - kdm forgets to quit plymouth if Xorg fails to start
Summary: kdm forgets to quit plymouth if Xorg fails to start
Alias: None
Product: Fedora
Classification: Fedora
Component: kdebase-workspace
Version: 15
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Ngo Than
QA Contact: Fedora Extras Quality Assurance
: 742712 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2011-09-09 05:09 UTC by Steve
Modified: 2012-07-28 03:27 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-07-28 03:27:27 UTC

Attachments (Terms of Use)
log of ssh session (2.70 KB, text/plain)
2011-09-22 12:44 UTC, Steve
no flags Details
repeat of log of ssh session (2.61 KB, text/plain)
2011-09-22 14:33 UTC, Steve
no flags Details
repeat of log of ssh session with redirected output (448.71 KB, text/plain)
2011-09-22 15:09 UTC, Steve
no flags Details

Description Steve 2011-09-09 05:09:20 UTC
Description of problem:
no getty on reboot in init level=5 with NVidia(tm)

Version-Release number of selected component (if applicable):

How reproducible:
all ways

Steps to Reproduce:
1. load new kernel
2. reboot
Actual results:
system has no ttys on restart

Expected results:
tty available on [ctrl]-[alt]-1..6

Additional info:
ssh from other box reload NVidia(tm) and reboot,
gui works and [ctrl]-[alt]-1..6 for tty works

Comment 1 Petr Lautrbach 2011-09-09 08:24:31 UTC
Fedora 15 uses systemd init by default. Is it really upstart?  Try 

# readlink /proc/1/exe

Comment 2 Steve 2011-09-09 12:11:31 UTC
here is the response, 
can test easily as any change in kernel will trigger this

# readlink /proc/1/exe                                                        

Comment 3 Lennart Poettering 2011-09-21 18:08:43 UTC
does "systemctl enable getty@.service" make this work?

Comment 4 Steve 2011-09-22 01:39:00 UTC

on reboot after a kernel change (usually an upgrade, but any kernel change will do it) there is no local command shell.  I am not using the DKMS for loading the
NVidia(tm) driver, but directly from the downloaded 
driver (NVIDIA-Linux-x86-280.13.run)

But sshd is running so a remote connection can install the graphics driver and on reboot to this kernel, both the gui and the getty are working.

Steps to Reproduce: (different description)
1. reboot with different kernel to the one with the NVidia(tm) driver
   screen with boot messages.
   system has no ttys on restart
2. ssh from other box reload NVidia(tm) and reboot,
   gui works and [ctrl]-[alt]-1..6 for tty works

Expected results:
tty available on [ctrl]-[alt]-1..6

Comment 5 Michal Schmidt 2011-09-22 12:11:38 UTC
From your comment it is not obvious to me whether you tried Lennart's suggestion or not. If you did and it did not help, please reproduce the problem, login via ssh, save the output of "systemctl dump" and attach it here. Thanks.

Comment 6 Steve 2011-09-22 12:44:23 UTC
Created attachment 524404 [details]
log of ssh session

Comment 7 Steve 2011-09-22 12:46:32 UTC
no ttys active before running commands
ttys are active after commands in attachment 524404 [details]

Comment 8 Michal Schmidt 2011-09-22 13:22:44 UTC
The attachment is truncated. The output of "systemctl dump" ought to be much longer.

Comment 9 Steve 2011-09-22 14:33:35 UTC
Created attachment 524421 [details]
repeat of log of ssh session

systemctl dump
finishes as submitted with the last line
needs [ctrl]-C to return to bash prompt

rebooted to working session and output is the same

Comment 10 Michal Schmidt 2011-09-22 14:37:05 UTC
That's because it displays in a pager (less/more). Use:
systemctl dump > dump.txt
And attach the resulting dump.txt.

Comment 11 Steve 2011-09-22 15:09:40 UTC
Created attachment 524426 [details]
repeat of log of ssh session with redirected output

command log

$ ssh -Y hvamm
thorfinn@hvamm's password:
Last login: Fri Sep 23 00:21:31 2011
[thorfinn@hvamm ~]$ su -
[root@hvamm ~]# readlink /proc/1/exe
[root@hvamm ~]# systemctl enable getty@.service
[root@hvamm ~]# systemctl dump > dump.txt
[root@hvamm ~]#

Comment 12 Michal Schmidt 2011-09-22 15:20:52 UTC
The dump shows plymouth-quit-wait.service is running and the getty services are waiting for it to finish.

Comment 13 Michal Schmidt 2011-09-22 15:27:52 UTC
prefdm.service is responsible for quitting plymouth in graphical.target. What login manager do you use? gdm, kdm, ... ?

Comment 14 Michal Schmidt 2011-09-22 16:07:41 UTC
I'm guessing you are using kdm, because I have just reproduced the bug here with it, using an intentionally broken xorg.conf. Reassigning to kdebase-workspace.

There are actually two bugs:
 - systemd ignores TimeoutSec= on oneshot services. This is a known problem
   and is listed on the upstream TODO.

 - kdm forgets to quit plymouth if Xorg fails to start.

Comment 15 Steve 2011-09-23 01:42:55 UTC
reply to Comment #13
$ ps aux | grep -i kdm
root      1405  0.0  0.0   4436   992 ?        Ss   01:02   0:00 /usr/bin/kdm -nodaemon
root      1441  4.9  0.7  92308 32140 tty1     Ssl+ 01:02  31:21 /usr/bin/X :0 vt1 -background none -nolisten tcp -auth /var/run/kdm/A:0-GZEJIa
thorfinn 18113  0.0  0.0   4440   772 pts/0    S+   11:41   0:00 grep --color=auto -i kdm

Comment 16 Michal Schmidt 2011-10-03 07:40:10 UTC
*** Bug 742712 has been marked as a duplicate of this bug. ***

Comment 17 Steve 2011-11-25 06:20:48 UTC
still present in Fedora-16

ssh from other machine
kill the plymouth process
now access to shell is available 
use the local shell to install driver
reboot to test (works in 3 tests)

Comment 18 Steve 2012-07-28 03:27:27 UTC
tested in kernels

system now works with access to other ttys when the graphical boot fails

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