Bug 113979 - rpm becomes unusable after libelf downgrading
Summary: rpm becomes unusable after libelf downgrading
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: rpm (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: i686 Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2004-01-20 21:50 UTC by Arik Fishbein
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-01-21 13:33:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Arik Fishbein 2004-01-20 21:50:04 UTC
Description of problem:
After downgrade of elfutils-libelf symlink to libelf becomes broken
and rpm can't be used

Version-Release number of selected component (if applicable):

change elfutils-libelf-0.91-3 to elfutils-libelf-0.89-1
change elfutils-0.91-3 to elfutils-0.89-1

How reproducible:
install latest errata update and downgrade to original version

Steps to Reproduce:
1. apply errata update
2. apply previously changes
3. ldd /bin/rpm
Actual results:

From rpm verbose log i can see that only postinstall phase activates
ldconfig job , but postunistall script gives message of : skipping
redundant "/sbin/ldconfig". That means that ldconfig was activated
when two versions of libelf shared object existed in /usr/lib

[root@tal root]# ldd /bin/rpm
        librpm-4.2.so => /usr/lib/librpm-4.2.so (0xb7588000)
        librpmdb-4.2.so => /usr/lib/librpmdb-4.2.so (0xb74aa000)
        librpmio-4.2.so => /usr/lib/librpmio-4.2.so (0xb746c000)
        libpopt.so.0 => /usr/lib/libpopt.so.0 (0xb7464000)
        libelf.so.1 => not found
        libbeecrypt.so.6 => /usr/lib/libbeecrypt.so.6 (0xb7446000)
        librt.so.1 => /lib/tls/librt.so.1 (0xb7431000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7421000)
        libbz2.so.1 => /usr/lib/libbz2.so.1 (0xb7412000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb72da000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb75eb000)
        libelf.so.1 => not found

[root@tal root]# rpm -qa | grep elf
rpm: error while loading shared libraries: libelf.so.1: cannot open
shared object file: No such file or directory

Expected results:
Normal rpm behaviour

Additional info:

Comment 1 Jeff Johnson 2004-01-21 03:57:08 UTC
What happens if you type /sbin/ldconfig as root?

Comment 2 Arik Fishbein 2004-01-21 08:19:12 UTC
If i run ldconfig after rpm transaction , everything works fine. 

Anyway , from strace log i can see that in postinstall phase ldconfig
runs for both elfutils-libelf-0.89-1 and elfutils-libelf-0.91-3 , but
since symlink to elfutils-libelf-0.91-3 created after
elfutils-libelf-0.89-1 , it overwrites previously created correct link.

Is it a bug in redundant "/sbin/ldconfig" checks?

Comment 3 Jeff Johnson 2004-01-21 13:33:44 UTC
Detecting when to run ldconfig precisely depends on
package ordering which is different on downgrade than upgrade

No easy answer for the reversed ordering on downgrade. Run ldconfig
after downgrading is adeqquate answer for an unusual circumstance.

Comment 4 James Olin Oden 2004-01-21 22:07:14 UTC

This seems like one of the few examples where erasure ordering 
would really be helpful.  Am I wrong?  Is there a bugzilla report
for sorting erasures?  If not I will write one...no patch guaranteed
on it though.


Comment 5 Jeff Johnson 2004-01-22 03:44:57 UTC
James: This isn't a erasure ordering problem.

rpm does erase before install when down-grading, watch what happens
by reinstalling a pkg with --force.

The ldconfig uniqification assumes install-before-erase and
so does not run ldconfig correctly.

The very simplest hack is, if ldconfig is ever run, run one
last time at end-of-transaction. That insures ldconfig has been
run, but is more than a bit hacky.

A better fix is far more complicated. There's a reason (which I do
not know) why erase-before-install was done, it's clear
from looking at the code that it was deliberate. The reason can be
rediscovered, of course; otherwise the implementation predates
my maintainership.

Comment 6 James Olin Oden 2004-01-22 15:14:39 UTC
Sorry I misunderstood the issue.  I completely understand that 
installs happen before erases, I just thought that you were saying 
that problem was due some how to non-deterministic order of erasures.
I obviously misinterpreted your comments (would not be the first
time (-;).

Actually, I think the order of install and then erase is quite good 
(this is a radical change of oppinion of course).  Basically, it 
allows the erases to do far less (i.e. remove less files), and there 
is far less chance the system would get into a really bad state (try
erasing glibc before installing the new one) for any programs spawned
during the rpm transaction.


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