Bug 736912

Fedora 15 uses systemd init by default. Is it really upstart?  Try 

# readlink /proc/1/exe

here is the response, 
can test easily as any change in kernel will trigger this

# readlink /proc/1/exe                                                        
/bin/systemd

does "systemctl enable getty@.service" make this work?

hi

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

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.

Created attachment 524404 [details]
log of ssh session

no ttys active before running commands
ttys are active after commands in attachment 524404 [details]

The attachment is truncated. The output of "systemctl dump" ought to be much longer.

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

That's because it displays in a pager (less/more). Use:
systemctl dump > dump.txt
And attach the resulting dump.txt.

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 -
Password:
[root@hvamm ~]# readlink /proc/1/exe
/bin/systemd
[root@hvamm ~]# systemctl enable getty@.service
[root@hvamm ~]# systemctl dump > dump.txt
[root@hvamm ~]#

The dump shows plymouth-quit-wait.service is running and the getty services are waiting for it to finish.

prefdm.service is responsible for quitting plymouth in graphical.target. What login manager do you use? gdm, kdm, ... ?

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.

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

*** Bug 742712 has been marked as a duplicate of this bug. ***

still present in Fedora-16

now 
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)

tested in kernels
kernel-PAE-3.4.4-5.fc17.i686                                 
kernel-PAE-3.4.5-2.fc17.i686                                 
kernel-PAE-3.4.6-2.fc17.i686
with 
plymouth-0.8.5-0.2012.04.27.2.fc17.i686

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