Bug 89779 - Using RPM to install a number of redhat supplied packages destroys database
Summary: Using RPM to install a number of redhat supplied packages destroys database
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm
Version: 9
Hardware: athlon
OS: Linux
high
high
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-04-28 08:23 UTC by Matt Hyne
Modified: 2005-10-31 22:00 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-04-29 17:05:11 UTC
Embargoed:


Attachments (Terms of Use)

Description Matt Hyne 2003-04-28 08:23:41 UTC
Description of problem:

Installation of additional RPMs on a Redhat Linux box resulted in the 'rpm -U'
process hanging (and the rpm process having to be sent a kill -9).

After this, the RPM database appeared to be totally unusable.  rpm -qa hangs and
no applications can either be installed or removed.  A complete format and
reinstall of RedHat Linux is required.

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

[root@security root]# rpm --version
RPM version 4.2
(default RedHat 9 revision)

How reproducible:

Have been able to reproduce this on multiple machines using both RedHat 8.0 and
Redhat 9.  Appears to be most succeptable when asking rpm to install multiple
files at once.

Steps to Reproduce:

1. Did a query of the rpm database:
   rpm -qa | grep freetype
1. Downloaded freetype-utils-2.1.3-6.i386.rpm and
freetype-demos-2.1.3-6.i386.rpm from RedHat mirror.
2. Installed using 
   rpm -U freetype-utils-2.1.3-6.i386.rpm freetype-demos-2.1.3-6.i386.rpm
3. Installation does not complete.  Need to kill rpm process.
4. No rpm functions will subsequently work.
    
Actual results:

Here is my log:

[root@security include]# rpm -qa | grep freetype
freetype-devel-2.1.3-6
freetype-2.1.3-6
[root@security include]# wget
ftp://mirror.internode.on.net/pub/redhat/linux/9/en/os/i386/RedHat/RPMS/freetype-utils-2.1.3-6.i386.rpm
--15:42:14-- 
ftp://mirror.internode.on.net/pub/redhat/linux/9/en/os/i386/RedHat/RPMS/freetype-utils-2.1.3-6.i386.rpm
           => `freetype-utils-2.1.3-6.i386.rpm'
Resolving mirror.internode.on.net... done.
Connecting to mirror.internode.on.net[192.231.203.130]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD /pub/redhat/linux/9/en/os/i386/RedHat/RPMS ... done.
==> PORT ... done.    ==> RETR freetype-utils-2.1.3-6.i386.rpm ... done.
Length: 23,566 (unauthoritative)

100%[=============================================================>] 23,566    
   48.65K/s    ETA 00:00

15:42:15 (48.65 KB/s) - `freetype-utils-2.1.3-6.i386.rpm' saved [23566]

[root@security include]# wget
ftp://mirror.internode.on.net/pub/redhat/linux/9/en/os/i386/RedHat/RPMS/freetype-demos-2.1.3-6.i386.rpm
--15:42:27-- 
ftp://mirror.internode.on.net/pub/redhat/linux/9/en/os/i386/RedHat/RPMS/freetype-demos-2.1.3-6.i386.rpm
           => `freetype-demos-2.1.3-6.i386.rpm'
Resolving mirror.internode.on.net... done.
Connecting to mirror.internode.on.net[192.231.203.130]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD /pub/redhat/linux/9/en/os/i386/RedHat/RPMS ... done.
==> PORT ... done.    ==> RETR freetype-demos-2.1.3-6.i386.rpm ... done.
Length: 63,901 (unauthoritative)

100%[=============================================================>] 63,901    
   51.19K/s    ETA 00:00

15:42:28 (51.19 KB/s) - `freetype-demos-2.1.3-6.i386.rpm' saved [63901]

[root@security include]# rpm -U freetype-utils-2.1.3-6.i386.rpm
freetype-demos-2.1.3-6.i386.rpm

Killed
[root@security include]# 

Now, attempting any other rpm functions results in rpm hanging:

[root@security include]# rpm -Uvv freetype-utils-2.1.3-6.i386.rpm
D: ============== freetype-utils-2.1.3-6.i386.rpm
D: Expected size:        23566 = lead(96)+sigs(344)+pad(0)+data(23126)
D:   Actual size:        23566
D: opening  db environment /var/lib/rpm/Packages joinenv
D: opening  db index       /var/lib/rpm/Packages rdonly mode=0x0

Or, doing a query:

[root@security w3cam-0.7.2]# rpm -qavv
D: opening  db environment /var/lib/rpm/Packages joinenv
D: opening  db index       /var/lib/rpm/Packages rdonly mode=0x0


Expected results:

It should never trash the rpm database - BAD

Additional info:

This is a big problem.  I have seen this on THREE installations so far - totally
different hardware and different applications being installed.  Rebuilding the
database did not work.  A complete reinstall of the machine was required wasting
days of work.

We will NOT roll out production machines with RH9 until the source of this is
found.  We cannot afford for customers to trash their RPM database by installing
additional RPMs.

Comment 1 Matt Hyne 2003-04-28 08:27:25 UTC
Here is my additional log after running rpm -vv --rebuilddb

[root@security rpm]# rpm --rebuilddb -vv
D: rebuilding database /var/lib/rpm into /var/lib/rpmrebuilddb.2022
D: creating directory /var/lib/rpmrebuilddb.2022
D: opening old database with dbapi 3
D: opening  db environment /var/lib/rpm/Packages joinenv
D: opening  db index       /var/lib/rpm/Packages rdonly mode=0x0
[hangs here]

Comment 2 Jeff Johnson 2003-04-29 17:05:11 UTC
Yup, the "rpm -qa | grep", if exited, can leave a stale lock.

FIxed in rpm-4.2-1 packages, currently at
   ftp://ftp.rpm.org/pub/rpm/test-4.2


Comment 3 Matt Hyne 2003-04-30 00:50:54 UTC
Is there a workaround other than upgrading RPM ?
Does Redhat plan to release an update for these affected packages ?

Thanks for the quick update.

Comment 4 Jeff Johnson 2003-04-30 13:41:52 UTC
Workaround for a bug? Sure, live with it ;-)

Errata has been pending forever, will eventually be released.

Comment 5 Matt Hyne 2003-04-30 23:03:33 UTC
I was actually looking for a more constructive answer, like is there a way to
manually remove the stale lock so I do not have to reinstall the entire box in
order to use RPM again ?

M

Comment 6 Jeff Johnson 2003-05-01 13:39:30 UTC
Sorry. Doing
    rm -f /var/lib/rpm/__db*
is usually all that's necessary if/when a stale
lock (due to missed signals on exit) are left.


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