Bug 111400
Summary: | rpm 4.1 segfaults during package operation | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Jamie <redhatbugzilla> | ||||||
Component: | rpm | Assignee: | Jeff Johnson <jbj> | ||||||
Status: | CLOSED WORKSFORME | QA Contact: | Mike McLean <mikem> | ||||||
Severity: | high | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 8.0 | ||||||||
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: | 2003-12-27 21:16:23 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: | |||||||||
Attachments: |
|
Description
Jamie
2003-12-03 03:10:03 UTC
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... |