We are currently upgrading our RH7.2 machine, and I want to upgrade gcc to version 3.3.1-5. To do this, I have to upgrade binutils to version 2.14.90.0.5-7(Rawhide). So, I do an rpm -Uvh binutils-* And it dies. /every time/ This may be a result of me doing a funky upgrade, things out of sync, etc, but I would hope RPM prevents me from _totally_ screwing my system up (but I know there are still ways to make things fubar ;-)) Reproduction: 1. rpm -Uvh binutils-* Package versions: rpm -q glibc glibc-2.3.2-11.9 rpm -q rpm rpm-4.0.4-7x.18 rpm -q binutils binutils-2.13.90.0.18-9
Created attachment 94658 [details] strace of the rpm command This is the last couple lines from strace after the "Preparing..." and the hash marks. If anyone wants to explain gdb I can get a backtrace ;)
Hmmm, upgrading glibc fixes this. Shouldn't I get an error rather than a segfault, though? Or have I thoroughly hosed my system by using an install procedure like this: 7.2 glibc --> 7.3 glibc --> 8.0 glibc (etc etc)
Dang it, I lied. Sorry for the spam :(
Presumably "lied" indicates the problem is fixed, otherwise reopen.
Sorry for all the garbage. I can confirm that this problem still exists. # rpm -ih kernel-2.4.20-20.9.i686.rpm warning: kernel-2.4.20-20.9.i686.rpm: V3 DSA signature: NOKEY, key ID db42a60e Segmentation fault Any ideas? The strace looks the same - ending with this: read(8, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\n\0"..., 1024) = 1024 fstat64(8, {st_mode=S_IFREG|0755, st_size=89516, ...}) = 0 old_mmap(NULL, 76504, PROT_READ|PROT_EXEC, MAP_PRIVATE, 8, 0) = 0x4040c000 mprotect(0x4041e000, 2776, PROT_NONE) = 0 old_mmap(0x4041e000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 8, 0x11000) = 0x4041e000 close(8) The changes on ld-linux seem to fail...
A --rebuilddb with rpm-4.1.1 for RHL 7.3 from ftp://ftp.rpm.org/pub/rpm/dist/rpm-4.1.x should fix. Can you try upgrading and then doing --rebuilddb?
Attempted to upgrade, same problems. With my current version (rpm-4.1-1.06), I ran --rebuilddb. This is pretty hard on an active server ;-) However, the same problem still exists. I cannot upgrade to the RPM packages because RPM segfaults.
Hmmm, this might be the dangling ptr problem from - fix: dangling pointer brain fart (#107835). If the following "fixes", then this is likely #107835: rm -f /var/lib/rpm/Pubkeys rpm -Uvh binutils-*.rpm Doing rpm --rebuilddb -vv will recreate the Pubkeys index. If this is #107835, then rpm-4.2.2-0.8 and later have the fix.
OTOH, the strace is not what I would expect from #107835. Looks more like a glibc mis-install somehow, the segfault occurs while loading rpm afaict.
Pulled the latest binutils from Fedora Project. mv /var/lib/rpm/Pubkeys /var/lib/rpm/Pubkeys.old rpm --rebuilddb -vv rpm -Uvh binutils* Still bombs out, same strace. If glibc was put in wrong, how should I put it back in safely? I wonder if this goes back to my incremental upgrade method... Yikes ;-)
You've upgraded to glibc from RHL 8.0? Try the rpm-4.1.1 for 8.0 then.
OK, I tried this, same result. I have been trying to do the steps listed here: http://www.rpm.org/hintskinks/repairdb/ I get this error: db_verify: Program version 3.2.9 doesn't match environment version 4.0.14 rpm -q db3 db3-3.2.9-4 I can't upgrade to the 'transitions', because my versions are higher than those. So, what are my options here? Could I force a downgrade to RH7.2 glibc/gcc/RPM? ___Should I?___
The msg will disappear if you do rm -f /var/lib/rpm/__db* You can either upgrade or downgrade. That's up to you. I'd suggest upgrading on general principles, not anything specific. Which is it? Up or down?
OK, let me try to be gutsy and go up ;) Best practice question: Should I pull Fedora Core stuff -- eg RPM, glibc, gcc... then resolve the dependency hell and go up? Or should I pick a lower target? If it turns out that it is a glibc misinstall(per comment 9), will pushing in the latest version resolve these problems? I want to be __very__ careful here and not make things more FUBAR than they are now, as a reinstall on this machine wouldn't be fun. Any advice?
This problem is ancient historyt. Reopen if still a problem.