From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031113
Description of problem:
In short: I rebuilt the rpmdb in the presence of a RedHat package
signing key that had apparently expired; now rpm -qa only shows the
non-RedHat rpms I have installed.
This morning I queried rpm to find out what version of openssl I have
[root@moby root]# rpm -qa | grep -i ssl
this returned nothing, so next I did:
[root@moby root]# rpm -qf /usr/share/ssl
which reported that the directory was (absurdly) not owned by any package!
Assuming that the rpmdb was whacked, I rebuilt it:
[root@moby root]# rm -f /var/lib/rpm/__db.* && rpm --rebuilddb
which produced hundreds of errors of the nature:
error: rpmdbNextIterator: skipping h# 108 Header V3 DSA signature:
BAD, key ID db42a60e
Then I checked to make sure that rpm had that key:
[root@moby root]# rpm -qa | grep gpg
Checking the RedHat web site, I discovered that the key there was
identical to one of the copies of the key rpm already had, so I
retrieved a (much longer) version of the key from the MIT keyserver.
After importing that key into rpm, I rebuilt the rpmdb without errors.
Alas the db is majorly hosed now: it only shows the 141 non-RedHat
rpms I have installed. Furthermore, the Package db verifies without
errors, but reloading the Package db:
[root@moby rpm]# mv Packages Packages-ORIG && /usr/lib/rpm/rpmdb_dump
Packages-ORIG | /usr/lib/rpm/rpmdb_load Packages
Left me in the same sorry state.
Version-Release number of selected component (if applicable):
I wish I could recover that information
Judging by the fact that rebuilding the rpmdb has worked as recently
as last week, the reputation of RedHat, and the wildly different
length of the public key on www.redhat.com and pgp.mit.edu, I
conjecture that the copy of the key that I had had been signed by a
key that expired, giving the bad key errors on the RedHat's own gpg key.
Needless to say, in my current state, I can't reproduce the problem
since the initial uncorrupted state of the rpmdb is inaccessible to me.
As for versions, as of yesterday, 1/1/04, my machine was up2date with
the RHN servers.
If there is anyway to rcover the rpmdb w/o re-installing the OS, I'd
*love* to hear it.
Yup. This is actually a "feature", all headers that
do not pass signature check are discarded with --rebuilddb.
The list of pkgs that you had installed should be in
If you locate and download those pkgs, then the database can
be recreated by adding --justdb --noscripts --notriggers
to a typical -Uvh operation.
Reinstalling as often just as expedient.
Thanks for the hint. I hope that your tongue was at least partially in
cheek wrt the "feature". 2 question/comments:
1) Alas, between Friday and today, my rpm has begun to refuse to
recognise the Fedora rpm-signing key as well. I retrieved both it and
the original, recentlynewly unacceptable RedHat rpm-signing key from
www.redhat.com. I don't see any traffic on the shrike & fedora lists
about other people having these problems. Is it only me? What's up w/
the keys on www.redhat.com? vs. those at pgp.mit.edu?
2) In fact, I do have the rpmpkg.log's and I have saved a copy of
every rpm I've installed (it's a long story) so I'd like to try your
re-creation trick. Sadly, since I noticed that the Fedora rpm-signing
key went south, rpm --import, rpm --rebuilddb, rpmdb_verify,
rpmdb_dump, & rpmdb_load all consistently either segfault or dump. So
- how much of /var/lib/rpm can I clobber and regenerate by
reinstalling all the rpms? The aforementioned long story also severely
dis-inclines me from reinstalling the OS.