Bug 86286
| Summary: | RPM Berkeley database repair utilities indicate incompatible DB version | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Generic User <belfrancis2001> |
| Component: | rpm | Assignee: | Jeff Johnson <jbj> |
| Status: | CLOSED WORKSFORME | QA Contact: | Mike McLean <mikem> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.0 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-03-24 19:10:07 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Use /usr/lib/rpm/rpmdb_{verify,dump,load} instead. Same
routines, use db-4.1.25, not db-4.0.14.
Jeff, I used rpmdb_dump and rpmdb_load to rebuild the Packages database. rpmdb_verify indicated things were okay as well. Next, I tried doing a rpm --rebuilddb and it segfaults. I tried rpmdb --rebuilddb and it hangs. I killed the hanging rebuild and removed the "rpmrebuild" temporary directories and tried them again with the -vv option. rpm --rebuilddb segfaults just when it is updating the MD5sum database for SHA1 and rpmdb --rpmrebuilddb also hangs at the same point. I decided to save the old /var/lib/rpm directory and replaced it with one generated by rpmdb --rebuilddb (ie: just renamed it to "rpm" under /var/lib). I ran rpmdb --rebuilddb again and this time it completes without any errors reported; however, whenever I try to perform an update or install, rpm segfaults. OK, something deeper is amiss.
Can you give me a pointer (i.e. URL, attachments won't work)
to a tarball of your database
cd /var/lib
tar czvf /tmp/rpmdb-86286.tar.gz rpm
and I'll take a look.
Understood. Not sure if I have a public area on the web where I can deposit my tar ball; however, I sent a direct e-mail with the tar ball attached. Hope it's alright :-/ Eeek, I've probably deleted the tar ball. Can you send again now that I'm looking? Thanks. e-mail is fine. Arrrghh... Just got off the blower with my ISP and they limit the size and volume of my e-mail and it does not seem like I can upload my tar-ball to my personal webspace either... so it looks like I will have to ftp my tar-ball to a site that you have available to receive an anonymous login or some customer/client ftp site (?). BTW, I did further research while trying to figure out whether you deleted the e-mail or not (I don't think you did for the reason above). To help with your diagnosis of the problem, I should also inform you of other factors that could be affecting the problem: 1) I am using glibc-2.3.1-51 2) Kernel version is kernel-2.4.18-26.8.0 If I understood correctly, there are significant differences in the way rpm database operations for version rpm-4.2 (4.1?) and rpm-4.0 are being performed. It appears that there is a new kernel locking mechanism in kernel-2.4.20 (NPTL? or some acronymn like that) that rpm-4.2 must be dependent on. Also the implication is that glibc-2.3.1-51 is required to implement the new kernel locking... so if I have rpm-4.2, glibc-2.3.1-51 BUT kernel-2.4.18 < kernel-2.4.20, I would imagine that could explain so of the segfaults/problems I am witnessing. Comments? Let me know where I can ftp my tar ball. Thanks, Frank Shim If segfaulting, I still need a tarball to figger.
Otherwise, there are versions of rpm-4.2/rpm-4.1.1/rpm-4.0.5
all with db-4.1.25 support staged at
ftp://people.redhat.com/jbj/test-*
ftp://ftp.rpm.org/pub/rpm/test-*
for all the usual distro versions.
I have no problems reading your database with rpm-4.1.1-1.7x (available at ftp://ftp.rpm.org/pub/rpm/test-4.1.1). Install manually using rpm2cpio if necessary. |
Description of problem: Attempting to repair the RPM database fails at the point of doing the following: $ db_verify /var/lib/rpm/Packages The message received is as follows: db_verify: Old or incorrect DB version; extraneous errors may result db_verify: DB->verify: Packages: DB_VERIFY_BAD: Database verification failed At this point, I have tried the following: $ db_dump -f Packages.dump /var/lib/rpm/Packages but get the following message: db_dump: /var/lib/rpm/Packages: unsupported hash version: 8 db_dump: open: /var/lib/rpm/Packages: Invalid argument Attempts to rebuild the RPM database also segfaults. Version-Release number of selected component (if applicable): $ db_verify -V Sleepycat Software: Berkeley DB 4.0.14: (November 18, 2001) $ db_dump -V Sleepycat Software: Berkeley DB 4.0.14: (November 18, 2001) $ rpm --version RPM version 4.2 How reproducible: Consistent Steps to Reproduce: 1. Start with RH8.0 with updated rpm-* at 4.1 version 2. Use rpm2cpio method to force upgrade of rpm-*,popt-* packages to 4.2 versions 3. Use rpm2cpio method to force upgrade elfutils-* packages needed by rpm 4.2 4. Perform the checks on the RPM database as outlined above Actual results: -- as outlined above -- Expected results: Not surprised that it is a versioning problem with regards to the database, but do require whether to upgarde the Berkeley db4 package or whether to there is a way of upgrading the RPM database without clobbering the hash version indicated. Additional info: