Red Hat Bugzilla – Bug 111400
rpm 4.1 segfaults during package operation
Last modified: 2007-04-18 12:59:55 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a)
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
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.... (
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):
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
...or at least the requirements of rpm should prevent the installation
of newer versions of glibc if they are incompatible
I have attemped the generic fix of rebuilding my database, which
succeeds fine, but does not rectify the situation.
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
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
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
BTW, thanks for your assistance on this, it's much appreciated.
There's a shell script version of rpm2cpio, look for
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...