Description of problem: no getty on reboot in init level=5 with NVidia(tm) Version-Release number of selected component (if applicable): 15 How reproducible: all ways Steps to Reproduce: 1. load new kernel 2. reboot 3. 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
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