Bug 467207

Summary: tty1 dead in runlevel 3
Product: [Fedora] Fedora Reporter: Mads Kiilerich <mads>
Component: plymouthAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: dcantrell, dvlasenk, krh, notting, otaylor, poelstra, rstrode, yusufma77
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-11-11 22:23:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 438943    

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-2.6.27.3-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-2.6.27.3-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-2.6.27.3-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-2.6.27.3-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-2.6.27.4-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-2.6.27.4-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-2.6.27.4-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-2.6.27.4-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 22 Jesse Keating 2008-11-11 22:23:47 UTC
And tagging for release.  closing.

Comment 23 Bill Nottingham 2008-11-14 16:07:53 UTC
*** Bug 471580 has been marked as a duplicate of this bug. ***