Bug 37465 - termcap entry for linux console too long?
Summary: termcap entry for linux console too long?
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anonftp   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2001-04-24 19:23 UTC by Tim Mann
Modified: 2007-04-18 16:32 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-04-25 16:04:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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 ->
-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

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

$ ls -l libtermcap* 
lrwxrwxrwx    1 root     system         19 Apr 24 12:54 libtermcap.so.2 ->
-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.

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