Bug 467207 - tty1 dead in runlevel 3
tty1 dead in runlevel 3
Product: Fedora
Classification: Fedora
Component: plymouth (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F10Blocker/F10FinalBlocker
  Show dependency treegraph
Reported: 2008-10-16 07:28 EDT by Mads Kiilerich
Modified: 2013-01-09 23:51 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-11-11 17:23:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mads Kiilerich 2008-10-16 07:28:53 EDT
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):
Comment 1 Ray Strode [halfline] 2008-10-20 16:59:36 EDT
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-21 23:38:13 EDT
Unfortunately, the bug is not fixed. Suggest to reopen it.

Comment 3 Mads Kiilerich 2008-10-22 08:31:55 EDT
Reopening, will test later
Comment 4 Mads Kiilerich 2008-10-23 12:38:16 EDT
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.
Comment 5 Yusuf Ma 2008-10-24 02:06:06 EDT
Updated to

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 09:34:34 EDT
Thanks for testing.
Comment 7 Mads Kiilerich 2008-10-24 09:41:50 EDT
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 09:51:56 EDT
don't forget to rebuild the initrd (as mentioned in comment 1) before rebooting.
Comment 9 Mads Kiilerich 2008-10-24 10:07:55 EDT
I just tested

plymouth-0.6.0-0.2008.10.23.2.fc10.i386 was installed

then I uninstalled and installed kernel- - 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.

Comment 10 Yusuf Ma 2008-10-25 02:42:29 EDT
Interesting. I am sure TTY1 login prompt works on my computer after update.
Comment 11 Mads Kiilerich 2008-10-27 05:59:03 EDT
Tested and confirmed solved with
kernel- nomodeset

Comment 12 Mads Kiilerich 2008-10-29 06:15:19 EDT
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- with nomodeset.

Comment 13 Ray Strode [halfline] 2008-10-29 10:01:53 EDT
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 14:04:33 EDT
A quick test showed that it does NOT work with

But I'm not fully updated at the moment - will test again next week
Comment 15 Bill Nottingham 2008-11-04 13:50:22 EST
Mads - any luck with an update and initrd rebuild?
Comment 16 Mads Kiilerich 2008-11-04 16:03:54 EST
Nope, no luck.

Tested with

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 12:21:45 EST
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 14:48:22 EST
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 15:02:47 EST
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 18:05:48 EST
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 22 Jesse Keating 2008-11-11 17:23:47 EST
And tagging for release.  closing.
Comment 23 Bill Nottingham 2008-11-14 11:07:53 EST
*** Bug 471580 has been marked as a duplicate of this bug. ***

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