Bug 104952 - RPM segfaults when trying to update to binutils from rawhide
Summary: RPM segfaults when trying to update to binutils from rawhide
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm   
(Show other bugs)
Version: 7.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2003-09-23 20:26 UTC by Owen Marshall
Modified: 2007-04-18 16:57 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-10-26 00:32:18 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
strace of the rpm command (2.12 KB, text/plain)
2003-09-23 20:31 UTC, Owen Marshall
no flags Details

Description Owen Marshall 2003-09-23 20:26:13 UTC
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

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 ;-))

1. rpm -Uvh binutils-*

Package versions:
rpm -q glibc
rpm -q rpm
rpm -q binutils

Comment 1 Owen Marshall 2003-09-23 20:31:03 UTC
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 ;)

Comment 2 Owen Marshall 2003-09-23 20:57:15 UTC
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)

Comment 3 Owen Marshall 2003-09-23 21:00:11 UTC
Dang it, I lied. Sorry for the spam :(

Comment 4 Jeff Johnson 2003-10-09 15:36:50 UTC
Presumably "lied" indicates the problem is fixed, otherwise reopen.

Comment 5 Owen Marshall 2003-11-06 22:20:53 UTC
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
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

The changes on ld-linux seem to fail...

Comment 6 Jeff Johnson 2003-12-27 21:00:28 UTC
A --rebuilddb with rpm-4.1.1 for RHL 7.3 from
should fix.

Can you try upgrading and then doing --rebuilddb?

Comment 7 Owen Marshall 2003-12-30 18:57:58 UTC
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.

Comment 8 Jeff Johnson 2004-02-10 19:38:32 UTC
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.

Comment 9 Jeff Johnson 2004-02-10 19:42:26 UTC
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.

Comment 10 Owen Marshall 2004-02-10 22:36:32 UTC
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 ;-)

Comment 11 Jeff Johnson 2004-02-11 06:54:58 UTC
You've upgraded to glibc from RHL 8.0?

Try the rpm-4.1.1 for 8.0 then.

Comment 12 Owen Marshall 2004-03-30 22:21:34 UTC
OK, I tried this, same result. I have been trying to do the steps
listed here:

I get this error:
db_verify: Program version 3.2.9 doesn't match environment version 4.0.14

rpm -q db3

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?___

Comment 13 Jeff Johnson 2004-03-31 01:42:19 UTC
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?

Comment 14 Owen Marshall 2004-03-31 20:53:30 UTC
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?

Comment 15 Jeff Johnson 2005-10-26 00:32:18 UTC
This problem is ancient historyt. Reopen if still a problem.

Note You need to log in before you can comment on or make changes to this bug.