Bug 159 - login problem on tty1; other ttys problem with enter key
Summary: login problem on tty1; other ttys problem with enter key
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: libtermcap
Version: 5.1
Hardware: i386
OS: Linux
high
high
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1998-11-22 23:13 UTC by swjenkins
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-03-29 21:10:11 UTC
Embargoed:


Attachments (Terms of Use)

Description swjenkins 1998-11-22 23:13:40 UTC
I have _serious_ problems when trying to login on text
console #1 (tty1).  Here's an example:

login: r Password:

I try to login as root, but as soon as I type "r" it
displays "Password:" and I haven't even hit enter!  This
problem only occurs on tty1.

Other times, the ENTER key displays a new prompt but on the
same line (no linefeed), like this:

[root@localhost ~]# [root@localhost ~]# [root@localhost ~]#
[root@localhost ~]# [root@localhost ~]# [root@localhost ~]#

Also, if I manage to get logged on on one of the bad tty's,
I can't move around in vi; the movement keys just display
the key character instead of moving it (ie, "j" go move down
on line displays a "j" on the screen but doesn't move down a
line).  This leads me to believe its some kind of termcap
problem.

These problems occurs on any tty at random, but not always
right away.  Sometimes it does it immediately after booting;
sometimes the system has been up for about 10 minutes and
then the problem kicks in.  It is very repeatable though.
It also appears that it you flood the tty with input you can
break it; try issuing one command after another with a bunch
of ENTERS thrown in.  Maybe I type too fast, but still this
shouldn't happen.  RH 4.2 & earlier never had these
problems.

I mentioned this at the the TCLUG installfest this past
weekend but no one else seemed to have the problem.

I know it's not hardware related because it does this on my
laptop AND on my desktop.  Plus another guy I know has the
same problem on different hardware (all hardware is intel
pentium based).  All systems with the problem are running RH
5.1.  At first we thought it might have been the updates,
but my testing disproved that theory.

Here's what I've tried, none of which fixed the problem:

1. clean install of RH 5.1, no updated rpm's applied (still
broken)
2. clean install of RH 5.1 with updated rpm's applied (still
broken)
3. clean install of RH 4.2 (system works ok here), upgrade
to RH 5.1 (broken then)
4. tried recreating RH 5.1 boot disks and repeating above
steps (still broke)
5. kill the shell or getty on the bad tty; still broke.  If
a shell was out there, now pressing ENTER displays "^M" and
you can no longer send a true ENTER to get the PC to accept
input.
6. "init q" to try to make init reput the getty out there;
it issues a new getty but that one too is still broken.
7. rebooting system (both cold & warm); neither works.

I had the ^M problem in the past with RH 3.03, 4.1, & 4.2
but only under this situation:
a) boot system to initdefault (runlevel 3).
b) init 1 for maintenance
c) then init 3 -- now whatever tty you were using in single
user, you couldn't send an ENTER; pressing ENTER just
displayed ^M.

This was not a serious problem because it was a rare
situation and I just learned to avoid it.  The problem with
RH 5.1 is serious and cannot be avoided.

The reason for my upgrade is to be able to install Oracle
(requires glibc) plus try tostay current with the OS.

Any help would greatly be appreciated.  I'm posting this to
bugzilla at redhat's site also.

Comment 1 Christian Hechelmann 1999-01-15 15:25:59 UTC
Observed this too. The symptoms indicate hosed terminal settings on a
tty (termio and friends). This may be caused by an application that
has either crashed or been killed in a way that prevented it from
resetting the termio settings. One can recover without a reboot from
the problem by issuing "stty </dev/THETTY" from another tty, though.

Comment 2 Preston Brown 1999-03-18 15:36:59 UTC
Dave, can you verify this with the steps he suggests?

Comment 3 Preston Brown 1999-03-29 21:10:59 UTC
We cannot duplicate this problem on 5.2 and later.


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