From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031002 Firebird/0.7+ Description of problem: Due to flaw in the recent errata update for glibc, pthread debugging info was stripped which made debugging threaded apps practically impossible. I needed this for an assignment, so to rectify this I installed the latest glibc 2.3.2 (release 101), which restored the threading symbols. I suspect this procedure has somewhat neutered rpm though, as it now segfaults whenever I try to modify my packages (install, up/downgrade, or erase). Due to this, I cannot regress my glibc version nor upgrade rpm itself to a newer version. I did a backtrace of the segfault in gdb, which I have attached. It seems the call to getpwnam is the exit point for rpm into the library, I would guess the library was at fault, but I have no other problems with it other than this one. I have looked at http://bugzilla.redhat.com/bugzilla/long_list.cgi?buglist=89122 , but I do not have compat listed in nsswitch.conf, so it should not apply. Some research seems to indicate that rpm in RH8 is staically linked to libnss, and the change in the binary interface of glibc between 3.2.1 and 2.3.2 is the root cause.... ( http://www.mail-archive.com/debian-glibc@lists.debian.org/msg04763.html ). If this is the case then surely a change in the rpm package's requirements is needed to stop this occurring to other systems. Anything else can be regressed, but not rpm if it stops working. :( Any solutions will be welcome. :) Version-Release number of selected component (if applicable): 4.1-1.06 How reproducible: Always Steps to Reproduce: On my system at least, 1. Install glibc 2.3.2 2. Attempt to modify your installed packages, eg. rpm -e postgresql-server Actual Results: rpm segfaults Expected Results: rpm should have performed the operation without segfaulting ...or at least the requirements of rpm should prevent the installation of newer versions of glibc if they are incompatible Additional info: I have attemped the generic fix of rebuilding my database, which succeeds fine, but does not rectify the situation. Versions: glibc version is glibc-2.3.2-101.i386.rpm rpm version is rpm-4.1-1.06.i386.rpm openssl version is openssl-0.9.6b-35.8.i386.rpm
Created attachment 96303 [details] Stack trace from segfault
This smells like the LDAP problem that causes statically linked binaries to segfault if/when LDAP passwords are used but nscd is not running. Are you using LDAP p[asswords? Try starting nscd (as root) service nscd restart Verify running, repeat the failing rpm command.
I'm not currently using LDAP, but I figured I'd try starting the service you reommended anyway. Suffice to say, it still segfaults, but I get a different stack trace now.
Created attachment 96320 [details] The new, different stack trace
Ok, now the update server load has reached levels so that my demo account can update from them, it seems up2date still works fine. Which is a small, but welcome bit of help. I take it up2date uses rpm to do its dirty work?
Hmmm, you may have mixed new fangled TLS encumbered modules with statically linked non-TLS rpm. That's my best guess looking at the stack strace, statically linked /bin/rpm is very tricky with thread local storage. Try rpm -V glibc glibc-common to insure no crud. You might try upgrading (use rpm2cpio if necessary) to rpm-4.2, or rpm-4.1.1, from ftp.rpm.org:/pub/rpm/dist. Use rpm-4.2 if you have upgraded to RHL 9 glibc, rpm-4.1.1 if RHL 8.0 glibc. up2date uses rpm-python which is linked to rpm libraries, yes.
*sigh* Homer just do something stupid. I followed your instructions, but I figured I'd try rpm 4.1 just in case, but even after rpm2cpio'ing it, it still segfaulted, and both stack traces were identical to the orignal traces. So I tried rpm2cpio on rpm 4.2 Oh dear, I didn't know how to back up everything that'd be changed so I just went for broke and I just extracted over the top, and...no segfault this time, but I now get told I'm missing libelf.so.1 *sigh* I remembered this was one of the dependecies which is why I couldn't upgrade rpm earlier, as I couldn't get hold of all of the rpms required to update openSSL and all of the software that depended on the existing version, libelf being amoung them, I think. But of course, rpm2cpio and the rpm libraries have now has been updated....and all require libelf.so.1, which I don't have, which I can't install from rpm, and now can't extract from a rpm. I'm pretty good at screwing myself up, aren't I? I found a perl script that claims to be able to have the functionality of rpm2cpio, but it insists all my rpm .rpm's have invalid headers. Which isn't true, as file says it is a V3, which is the version supported by the script (http://www.linuxmafia.com/pub/linux/utilities-general/rpm2cpio, should you be interested) I'm gonna keep looking for an alternative to rpm2cpio so I can get the old rpm functionality back as I suspect adding the libelf.so.1 file will probably break yet more things, as seems about par for the course for me BTW, thanks for your assistance on this, it's much appreciated.
There's a shell script version of rpm2cpio, look for /usr/lib/rpm/rpm2cpio.sh. Using that (with some patience) should be able to fix anything but /var/lib/rpm/Packages (so make sure that is backed up). Everything else is fixable. Packages restorable, too, but reinstall is often most expedient.
I just resolved this problem with rpm2cpio. The problem is that rpm- 4.1-1.06 works with glibc-2.2.93-5 but not glibc-2.3.2-11.9. I had to install rpm-4.2-0.69. First, I used rpm2cpio to carefully install all dependecies of the new rpm. Once they were installed, I used rpm2cpio to install rpm (unCPIOing to a temp directory and using cp -b so I had backups in case the manual install hosed my system.) Then, rpm started working, and I was able to tell rpm to "install" all the packages I just cpio'd to update the rpm database. Adding libelf.so.1 didn't cause conflicts of any kind for me (it seems to co-exist with the older libelf), but I understand why you would be suspicious (given that upgrading another package (glibc) "breaks" rpm without warning the user first...) Thanks to everyone for helping me get this resolved...