Bug 37465
Summary: | termcap entry for linux console too long? | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Tim Mann <redhat-bugzilla> |
Component: | anonftp | Assignee: | 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
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. |