Bug 159 - login problem on tty1; other ttys problem with enter key
login problem on tty1; other ttys problem with enter key
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: libtermcap (Show other bugs)
5.1
i386 Linux
high Severity high
: ---
: ---
Assigned To: David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1998-11-22 18:13 EST by swjenkins
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-03-29 16:10:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description swjenkins 1998-11-22 18:13:40 EST
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 10:25:59 EST
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 10:36:59 EST
Dave, can you verify this with the steps he suggests?
Comment 3 Preston Brown 1999-03-29 16:10:59 EST
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.