Description of problem: rpm give segmentation fault when installing or erasing packages Version-Release number of selected component (if applicable): 4.1-1.06 How reproducible: every time Steps to Reproduce: 1. rpm -i *anypackage*.rpm or 2. rpm -u *anypackage*.rpm or 3. rpm -e *anypackage*.rpm Actual results: Gives error: "Segmentation fault" and dies. Expected results: Istall, update or erase the package as requested. Additional info: Everything else works fine. Rpm checks the packages and dependencies and reports in case of dependencies correctly. Queries and (database) rebuilds also work fine. When testing, even with --nodeps and/or --force still everythings fine. It is when actually trying to install, upgrade or remove a package when rpm just dies. It does not hang, though the symptoms are the same - /var/lib/rpm shows the __db.00? files.
Upgrading to rpm-4.1.1 from ftp.rpm.org recommended. Does "rpm -qa" segfault?
No. It shows installed packages as it should.
OK. Does problem track with specfic package or generally? (add -vv for copious detail). You might try LD_ASSUME_KERNEL=2.4.19 rpm ... prefix, that changes locking. You might also try adding --nosignature and/or --nodigest. Any of that help?
If it's any help, I get the exact same error with a different RPM, and it started right after I went to glibc2.3 (2.3.2-98, from a bunch of RPMs) on Redhat7.2. RPM4.0.4-7x (installed through rpm) segfaults right after install, erase or upgrade. RPM 4.1 (from .i386.tar.gz) segfaults in exactly the same spot. Doesn't matter which rpm, everything fails. -qa gives a good list, --test also gives no errors, dependencies work more or less ok, but (imho) as soon as it needs to write something to the database it just segfaults. I tried recompiling rpm from scratch, but I'm missing some parts (complains about db3 in particular, probably needs db3-devel) which I do not have installed according to 'rpm -qa', but cannot install either cause rpm segfaults. Using strace, I see it die right after doing something with ld-linux.so.2. (I tried to manually override it back to the older version, totally hosed my system, hit myself on the head - should've known glibc is connected to everything). Tried rpm --rebuilddb, completes without errors, but doesn't help. In other words, *exactly* the same problem the bugstarter is having.
Bug# 86197 lists exactly my behaviour regarding segfault, any chance this bug is the same? Check if 'nscd -d' also segfaults, if so, let's merge the two bugs.
If this helps anyone, I am having the same problem on RH 8 with rpm-4.1-1.06 after upgrading glibc to 2.3.2-11.9 using the glibc RPMs. rpm -vv gives me the following lines when erasing a package: (snip) D: erase: joe-2.9.7-1 has 12 files, test = 0 D: opening db index /var/lib/rpm/Name create mode=0x42 D: read h# 502 Header sanity check: OK Segmentation fault rpm -vv gives me the following lines when installing a package: (snip) D: ========== +++ j2re-1.4.2_02-fcs D: Expected size: 13778791 = lead(96)+sigs(100)+pad(4)+data(13778591) D: Actual size: 13778759 D: install: j2re-1.4.2_02-fcs has 669 files, test = 0 Segmentation fault I don't know how to safely downgrade to the older version of glibc without rpm, so I'm stuck here...
We have succesfully worked around this problem! Actually, it seems, that the party to blame here isn't rpm, but glibc as J. F. van Baarlen mentioned. I too had the problem occuring right after installing upgrade-rpms (from funet.fi - mirror of redhat.com). I think our glibc was 2.2.93-5 and we tried to upgrade to the formentioned 2.2.98-X. What we did then? We restored the original (non-buggy) state of the operating systems from backups. After that we still had some problems with RPM-based installation depending on glibc. This could be worked around stating the environment variable LD_ASSUME_KERNEL=2.2.5. However this did not solve all our issues, just enough to get the rpm to work (or, at least to install and upgrade). Then we upgraded (since we got rpm to work) the whole bunch of glibcs to version 2.3.2-4.80.6. Since the processor is P4 or greater, we took extra care that the glibc packages that were available as i686.rpm were installed instead of i386.rpm. Also we took care to upgrade the glibcs so that every package and file would really be replaced with the --replacepkgs --replacefiles options. Now everything works fine - if you don't count the one little thing; operating system now "speaks" finnish every now and then even though every step of way have chosen us-english as our operating system language...
Causes Segmentation fault under Fedora Core 1, rpm 4.2.1-0.30 and glibc-2.3.2-101 while reading DSA signatures. Doesn't install, update or rebuild database
This appears to be the same problem that is in bug 111400 (which was closed as NEEDINFO for some reason.) I installed the same versions of RPM and LIBC as the guy in 111400 and I'm getting the same problem. So, the bug seems to be easily reproducible.
One report per bug, please, me too's just confuse everything. tommi: do you have fix yet?
Ah, yes, happy customer, WORKSFORME.
Yes, a happy customer - thanks to you all! I hope someone comes up with a better solutions for this, since ours solely depends on having a working backup set - which is not obviously allways the case. Looking back at the problem I should warn everyone though... In the previous RH versions (7.0 and earlier if I recall correctly) one could allways install .i386 rpm-package regardless of the "required" or "correct" rpm-package (.i386, .i586 or .i686 depending on your platform, of course). This is not the case anymore (as one one knows if one does the good-old RTFM... ;-). So in future be careful with the packages - always be sure that it really does suit your environment. Thanks to you all, and have a good '04!