Try
   rm -f /var/lib/rpm/__db*

DOes that fix?

The "rpm --rebuilddb" error looks like the known, harmless bug (in bug 83281).

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?

> Try
>   rm -f /var/lib/rpm/__db*
> DOes that fix?

It does not...

Does not what? Removing the __db* files should fix the futex
problem, won't fix the (harmless) error message from --rebuilddb.

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

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.

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

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

This problem is resolved by running /usr/lib/rpm/rpmdb_loadcvt
to convert from db-4.1.25 -> db-4.0.14 format.

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

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

Thanks.  rpmdb_loadcvt is not included in the RedHat rpm distribution.
I am downloading rpm from rpm.org even as I type.

Downloaded and installed rpm-4.2-1.i386.rpm from
ftp.rpm.org/pub/rpm/dist

There is no rpmdb_loadcvt in the package!

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