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):
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)
Unfortunately, the bug is not fixed. Suggest to reopen it.
Reopening, will test later
Confirmed NOT working with
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.
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.
Thanks for testing.
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
don't forget to rebuild the initrd (as mentioned in comment 1) before rebooting.
I just tested
plymouth-0.6.0-0.2008.10.23.2.fc10.i386 was installed
then I uninstalled and installed kernel-22.214.171.124-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.
Interesting. I am sure TTY1 login prompt works on my computer after update.
Tested and confirmed solved with
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-126.96.36.199-58.fc10.i686 with nomodeset.
Can you try
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.)
A quick test showed that it does NOT work with
But I'm not fully updated at the moment - will test again next week
Mads - any luck with an update and initrd rebuild?
Nope, no luck.
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.
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
If you change /etc/event.d/quit-plymouth to 'start on stopping ...' for all the cases, does it work for you?
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?
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
Will be in 8.86-1.
And tagging for release. closing.
*** Bug 471580 has been marked as a duplicate of this bug. ***