Bug 37465

Summary: termcap entry for linux console too long?
Product: [Retired] Red Hat Linux Reporter: Tim Mann <redhat-bugzilla>
Component: anonftpAssignee: Bernhard Rosenkraenzer <bero>
Status: CLOSED RAWHIDE QA Contact: Aaron Brown <abrown>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-04-25 16:04:29 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:

Description Tim Mann 2001-04-24 19:23:44 UTC
Whenever I log in on the console with RH7.1, I get the message "tgetent:
warning: termcap entry too long".  Typing "echo $TERM" returns "linux".

Comment 1 Bernhard Rosenkraenzer 2001-04-24 19:33:42 UTC
I can't reproduce this, and nobody reported anything like this in the beta 
phase. Make sure you aren't using a broken ~/.termcap or ~/.terminfo. Also, 
make sure nobody messed up your termcap, ncurses or libtermcap packages.



Comment 2 Tim Mann 2001-04-24 20:40:34 UTC
This seems to have been caused by a bug in RPM (??!).  I had a copy of
libtermcap.so.2.0.5 from 1996 lying around in the /lib directory.  For some
reason I don't understand, installing libtermcap-2.0.8-26.i386.rpm creates
/lib/libtermcap.so.2.0.8 as a hard link to this old file instead of installing
the correct new file:

$ cd /lib
$ ls -l libtermcap*
lrwxrwxrwx    1 root     system         19 Apr 24 11:40 libtermcap.so.2 ->
libtermcap.so.2.0.8
-rwxrwxr-x    2 root     system      11419 Jul 28  1996 libtermcap.so.2.0.5
-rwxrwxr-x    2 root     system      11419 Jul 28  1996 libtermcap.so.2.0.8

I was able to repeat the rpm error by running "rpm -e --nodeps libtermcap"
(which removed libtermcap.so.2.0.8 but left libtermcap.so.2.0.5 in place), then
running "rpm -i libtermcap-2.0.8-26.i386.rpm", which recreated the above
situation.

At this point I was pretty puzzled.  I rebooted and forced an fsck just to make
sure I didn't have some bizarre filesystem corruption.  There were no errors.

Finally, I moved libtermcap.so.2.0.5 to another directory, removed the other two
files, and did "rpm -i --force libtermcap-2.0.8-26.i386.rpm".  This fixed the
problem:

$ ls -l libtermcap* 
lrwxrwxrwx    1 root     system         19 Apr 24 12:54 libtermcap.so.2 ->
libtermcap.so.2.0.8
-rwxr-xr-x    2 root     system      12120 Oct  7  2000 libtermcap.so.2.0.8



Comment 3 Bernhard Rosenkraenzer 2001-04-25 13:54:29 UTC
This is most definitely a local issue. Our best guess is that you installed 
some ridiculous package that owns a trigger on libtermcap and overwrites the 
library with its own files.

Does rpm -qf /lib/libtermcap.so.2.0.5 show anything?

This is definitely not a Red Hat package by the way, we've shipped 2.0.8 even 
in Red Hat Linux 4.2, which is as far back as our archives go.



Comment 4 Tim Mann 2001-04-25 16:04:25 UTC
Excellent guess.  I looked around some more, and found that the trigger script
causing the problem is in the Red Hat package anonftp-4.0-4.  I don't know where
the file /lib/libtermcap.so.2.0.5 came from originally, but its presence tickles
a bug in this trigger script.  Here are the key lines:

copy() { ln -f "$1" "$2" 2>/dev/null || cp -df "$1" "$2"; }
rm -f /var/ftp/lib/libtermcap.so.*.*.* &>/dev/null || :
copy /lib/libtermcap.so.*.*.* /var/ftp/lib

Stop a moment and consider what that copy() function is going to do when
/lib/termcap.so.*.*.* expands to more than one filename.  Yep, it will replace
the second expansion with a hard link to the first one.  That's exactly what
happened here.  The new 2.0.8 version got replaced with a hard link to the bogus
old 2.0.5 version.




Comment 5 Bernhard Rosenkraenzer 2001-04-25 16:17:25 UTC
Fixed in anonftp-4.0-5.

It's still partially a setup problem, though - you should never have 2 files 
matching libsomething.so.*.*.* because there's no need for the older one, 
especially not in /lib.