|Summary:||tty1 dead in runlevel 3|
|Product:||[Fedora] Fedora||Reporter:||Mads Kiilerich <mads>|
|Component:||plymouth||Assignee:||Ray Strode [halfline] <rstrode>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||dcantrell, dvlasenk, krh, notting, otaylor, poelstra, rstrode, yusufma77|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-11-11 22:23:47 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description Mads Kiilerich 2008-10-16 11:28:53 UTC
Description of problem: (Bug 466492 has been hijacked and moved to gdm, so I create this instead ;-) I withdraw my withdrawal and state again that:) When booting directly to runlevel 3 then tty1 is dead. I have seen it work and I have seen it not working. I am confused, but I don't know if I am confused and thus made a bogus test, or if the nature of the problem confuses me ... Version-Release number of selected component (if applicable): initscripts-8.84-1.i386
Comment 1 Ray Strode [halfline] 2008-10-20 20:59:36 UTC
This should be fixed with the plymouth in tomorrow's rawhide. To test it, you'll need to rebuild the initrd with /sbin/mkinitrd -f /boot/initrd-$(uname -r).img $(uname -r) (or install a new kernel which does that step for you)
Comment 2 Yusuf Ma 2008-10-22 03:38:13 UTC
Unfortunately, the bug is not fixed. Suggest to reopen it. kernel-126.96.36.199-30.rc1.fc10.i686 plymouth-0.6.0-0.2008.10.17.3.fc10.i386
Comment 3 Mads Kiilerich 2008-10-22 12:31:55 UTC
Reopening, will test later
Comment 4 Mads Kiilerich 2008-10-23 16:38:16 UTC
Confirmed NOT working with kernel-188.8.131.52-39.fc10.i686 plymouth-0.6.0-0.2008.10.21.2.fc10.i386 Nothing is echoed when the login name is written on tty1. But on pressing enter I get a password prompt. And when I get a new login prompt after failing login then it works as usual. Running with nomodeset.
Comment 5 Yusuf Ma 2008-10-24 06:06:06 UTC
Updated to kernel-184.108.40.206-39.fc10.i686 plymouth-0.6.0-0.2008.10.21.2.fc10.i386 It seems that this problem has been fixed. TTY1 is back to normal. I did not use nomodeset. However, if booted into runlevel 5, TTY1 still does not work. See Bug 467634.
Comment 6 Ray Strode [halfline] 2008-10-24 13:34:34 UTC
Thanks for testing.
Comment 7 Mads Kiilerich 2008-10-24 13:41:50 UTC
yusuf - are you sure, have you tried to log in on tty1 iirc your problem was black screen on tty1 this issue is about a frozen login prompt and sorry, my shift key is dead - i will retest when i reboot
Comment 8 Ray Strode [halfline] 2008-10-24 13:51:56 UTC
don't forget to rebuild the initrd (as mentioned in comment 1) before rebooting.
Comment 9 Mads Kiilerich 2008-10-24 14:07:55 UTC
I just tested plymouth-0.6.0-0.2008.10.23.2.fc10.i386 was installed then I uninstalled and installed kernel-220.127.116.11-39.fc10.i686 - and thus build a new initrd Then I booted to runlevel 3 with nomodeset and got exactly the same behaviour as in comment #4: login prompt on tty1, but no echo of username first time. Reopening.
Comment 10 Yusuf Ma 2008-10-25 06:42:29 UTC
Interesting. I am sure TTY1 login prompt works on my computer after update.
Comment 11 Mads Kiilerich 2008-10-27 09:59:03 UTC
Tested and confirmed solved with kernel-18.104.22.168-47.rc3.fc10.i686 nomodeset plymouth-0.6.0-0.2008.10.24.1.fc10.i386 initscripts-8.84-1.i386 Closing.
Comment 12 Mads Kiilerich 2008-10-29 10:15:19 UTC
Argh. Oh no. Now I see the problem again: Normal password prompt on tty1 in runlevel 3. But nothing is echoed when I enter my login name, so it seems dead. But on pressing enter I get a password prompt. And when the login fails and I get a new login prompt then it works as usual. kernel-22.214.171.124-58.fc10.i686 with nomodeset. plymouth-0.6.0-0.2008.10.27.5.fc10.i386 initscripts-8.84-1.i386 Reopening.
Comment 13 Ray Strode [halfline] 2008-10-29 14:01:53 UTC
Can you try 0.6.0-0.2008.10.27.7.fc10 ? When I fixed bug 468880, I noticed a problem that would cause this bug, too, and changed it as well. Things should be square now. (This bug is totally a twisted game of pong, so I'm going to move to MODIFIED instead of closing until you can confirm. Sorry for all the back and forth.)
Comment 14 Mads Kiilerich 2008-10-31 18:04:33 UTC
A quick test showed that it does NOT work with kernel-126.96.36.199-69.fc10.i686 plymouth-0.6.0-0.2008.10.27.7.fc10.i386 But I'm not fully updated at the moment - will test again next week
Comment 15 Bill Nottingham 2008-11-04 18:50:22 UTC
Mads - any luck with an update and initrd rebuild?
Comment 16 Mads Kiilerich 2008-11-04 21:03:54 UTC
Nope, no luck. Tested with kernel-188.8.131.52-73.fc10.i686 xorg-x11-drv-ati-6.9.0-41.fc10.i386 plymouth-0.6.0-0.2008.10.30.2.fc10.i386 Modeset or not makes no difference. I think that I once saw that when I switched to tty2 and back to tty1 then it started working. But I can't reproduce that ... Btw, my grub menu is shown on every boot - don't know if that can have any influence.
Comment 17 Ray Strode [halfline] 2008-11-07 17:21:45 UTC
so this is a race between /etc/event.d/tty1 and /etc/event.d/quit-plymouth i think. tty1 gets started before plymouth gets done quitting and then plymouth goes bonkers because it's tty got taken over and then it crashes I think. we should (do both): 1) force quit-plymouth to run first 2) make plymouth not go bonkers when the tty gets taken over
Comment 18 Bill Nottingham 2008-11-10 19:48:22 UTC
If you change /etc/event.d/quit-plymouth to 'start on stopping ...' for all the cases, does it work for you?
Comment 19 Ray Strode [halfline] 2008-11-10 20:02:47 UTC
didn't see any problem after several reboots with that change, but the problem has always been very intermittent for me anyway. Mads, does it fix it for you?
Comment 20 Mads Kiilerich 2008-11-10 23:05:48 UTC
I have had several boots where it worked fine, so, yes, I think that fixes it. And FWIW I agree that it makes sense to solve it this way. I propose updating the description: # This service triggers plymouth to quit when we reach the end of the boot # cycle. "stopping rcX" is used to ensure that this completes before "stopped # rcX" which starts tty1. In level 5 prefdm handles this differently. start on stopping rc2 start on stopping rc3 start on stopping rc4
Comment 21 Bill Nottingham 2008-11-11 17:05:06 UTC
Comment 22 Jesse Keating 2008-11-11 22:23:47 UTC
And tagging for release. closing.