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