Bug 89931 - rpm --rebuilddb and red-carpet error out after RH9 upgrade
Summary: rpm --rebuilddb and red-carpet error out after RH9 upgrade
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm   
(Show other bugs)
Version: 9
Hardware: i686 Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: Mike McLean
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-04-29 22:03 UTC by Jamie Zawinski
Modified: 2007-04-18 16:53 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-05-02 15:05:45 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Jamie Zawinski 2003-04-29 22:03:59 UTC
(maybe this is a dup, I can't tell.)

I had a Red Hat 8.0 system + Ximian.
I upgraded it to RH 9.0.
After doing so, red-carpet would no longer work:

    rpmdb: unable to join the environment
    error: db4 error(11) from dbenv->open:
        Resource temporarily unavailable
    error: cannot open Packages index using
        db3 - Resource temporarily unavailable (11)

Nor would "rpm --rebuilddb":

    error: db4 error(16) from dbenv->remove:
       Device or resource busy

I upgraded a second, similar machine in the same way.
This time I did "rpm --rebuilddb" on the RH 8.0 system
immediately before doing the upgrade; after upgrading
to RH 9.0, it had exactly the same problem.

Current (RH9) versions:

    rpm-4.2-0.69
    gdbm-1.8.0-20
    db4-devel-4.0.14-20
    compat-db-3.3.11-4
    db4-4.0.14-20
    red-carpet-1.4.3-1.ximian.4

Comment 1 Jeff Johnson 2003-04-30 13:34:54 UTC
Try
   rm -f /var/lib/rpm/__db*

DOes that fix?

Comment 2 Michael Young 2003-04-30 15:04:55 UTC
The "rpm --rebuilddb" error looks like the known, harmless bug (in bug 83281).

Comment 3 Radhesh 2003-04-30 20:24:45 UTC
I too found this happen in a similar situation.

my rpm processes stated to lock up at 
strace -p 26922
futex(0x40594e90, FUTEX_WAIT, 0, NULL
 <unfinished ...>


So I tried the familiar procedure which now fails on 9.0
;rm -rf __db*
;rpm --rebuilddb
error: db4 error(16) from dbenv->remove: Device or resource busy

I guess the Packages file is corrupted as that is the place where strace locks
up. Is there a db_rebuild command to recover from this?

Comment 4 Jamie Zawinski 2003-05-01 03:00:15 UTC
> Try
>   rm -f /var/lib/rpm/__db*
> DOes that fix?

It does not...


Comment 5 Jeff Johnson 2003-05-01 13:54:11 UTC
Does not what? Removing the __db* files should fix the futex
problem, won't fix the (harmless) error message from --rebuilddb.

Comment 6 Jamie Zawinski 2003-05-01 22:24:30 UTC
"After deleting those files, behavior does not change."

rpm --rebuilddb prints the same error message -- which
you say is harmless.  Ok.

But Red Carpet still doesn't work -- though I see that now
the error message is slightly different.  It used to say

    rpmdb: unable to join the environment
    error: db4 error(11) from dbenv->open:
        Resource temporarily unavailable
    error: cannot open Packages index using
        db3 - Resource temporarily unavailable (11)

and now it says

    rpmdb: /var/lib/rpm/Packages:
        unsupported hash version: 8
    error: cannot open Packages index using
        db3 - Invalid argument (22)

Comment 7 Jeff Johnson 2003-05-01 22:57:48 UTC
Ah, that's db-4.0.14 vs. db-4.1.25 incompatibility.

Run (as root)
    /usr/lib/rpm/rpmdb_loadcvt

Does that fix Red Carpet? If so, redcarpet needs to use
a version of rpm compiled with db-4.1.25.

Comment 8 Jamie Zawinski 2003-05-01 23:14:10 UTC
In what RPM do I find /usr/lib/rpm/rpmdb_loadcvt?  I have:

    % ls /usr/lib/rpm/rpmdb_*
    /usr/lib/rpm/rpmdb_deadlock* /usr/lib/rpm/rpmdb_stat*
    /usr/lib/rpm/rpmdb_dump*     /usr/lib/rpm/rpmdb_svc*
    /usr/lib/rpm/rpmdb_load*     /usr/lib/rpm/rpmdb_verify*

    redhat-rpm-config-8.0.21-1
    librpm404-4.0.4-8x.27
    rpm-devel-4.2-0.69
    rpm-build-4.2-0.69
    rpm-4.2-0.69
    rpm-python-4.2-0.69
    rpm404-python-4.0.4-8x.27

    db4-utils-4.0.14-20
    db4-4.0.14-20
    gdbm-1.8.0-20
    gdbm-devel-1.8.0-20
    db4-devel-4.0.14-20


Comment 9 Jamie Zawinski 2003-05-01 23:31:04 UTC
Thanks, that fixed it -- it lets red-carpet run, anyway.
Seems that Ximian still don't have the backend set up
for RH9, though.  But it did make the RPM errors go away.

(This red-carpet was left over from my RH8 installation --
that trick had worked when I upgraded from RH7 to RH8,
but I guess not this time.)

Comment 10 Jeff Johnson 2003-05-02 15:05:45 UTC
This problem is resolved by running /usr/lib/rpm/rpmdb_loadcvt
to convert from db-4.1.25 -> db-4.0.14 format.

Comment 11 Lloyd Kvam 2003-07-30 19:13:15 UTC
Comment 8 asks:
In what RPM do I find /usr/lib/rpm/rpmdb_loadcvt?

Comment 9 says:
Thanks, that fixed it -- it lets red-carpet run, anyway.

We are missing the information that would provide the fix!!!
Where do I find rpmdb_loadcvt?????

Comment 12 Jeff Johnson 2003-07-30 19:35:22 UTC
rpmdb_loadcvt is found in any/all of
    rpm-4.2
    rpm-4.1.1
    rpm-4.0.5
Packages available in the usual place
    ftp://ftp.rpm.org/pub/rpm/dist

Comment 13 Lloyd Kvam 2003-07-30 19:51:48 UTC
Thanks.  rpmdb_loadcvt is not included in the RedHat rpm distribution.
I am downloading rpm from rpm.org even as I type.

Comment 14 Lloyd Kvam 2003-07-30 20:12:19 UTC
Downloaded and installed rpm-4.2-1.i386.rpm from
ftp.rpm.org/pub/rpm/dist

There is no rpmdb_loadcvt in the package!

Comment 15 Lloyd Kvam 2003-07-30 21:45:09 UTC
I had upgraded from rpm-4.2-0.69 (the RedHat 9 package) to rpm-4.2-1 from
ftp.rpm.org as mentioned earlier.

Now I went back and ran rpm --rebuilddb -vv #(the -vv just spews lots of details
to the screen so it will be obvious if it fails)

This worked.  Jeff forwarded the rpmdb_loadcvt script to me, but it wasn't needed.

In my case it was up2date that was failing.  It now works fine!

Thanks


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