Description of Problem: When executing $ rpm -U dummy-0.0.1-1.i386.rpm $ rpm -U dummy-0.0.1-1.i386.rpm --force $ rpm -e dummy I get the error message error: db3 error(-30985) from db->verify: DB_VERIFY_BAD: Database verification failed at any any modifying operation. Rebuilding the packages and removing the hash-files does not help. How Reproducible: everytime Additional Information: rpm-4.0.3-0.84 If not reproducible, I can provide the rpm-database.
Created attachment 25931 [details] sample src.rpm
Does rm -f /var/lib/rpm/__db* rpm --rebuilddb fix your problem?
No. After rebuilding the db it seems that single operations (e.g. rpm -e <one package>) don't produce the warning anymore. But when executing a more complex one (e.g. rpm -e <package1> <package2>, where p1 requires p2), it is back. I have a reference machine where the dummy-package was not installed. There the message does not appears.
A pointer (i.e. URL, not a bugzilla attachment) to a tarball of your database, please cd /var/lib tar czvf /tmp/rpmdb3-50679.tar.gz rpm So, if I understand what you're saying, the problem reproduces itself soley because the package is installed? Can you verify that the problem goes away when package is removed, reappears when package is installed?
Here's most of the problem %files %defattr(-,root,root) /tmp/* as that's gonna pick up all sorts of crap like named pipes and sockets and other bizarre file types and put them in your package. I have no clue whether the right thing happens, when, for example, a socket is included in a package. Off to see what crap has been picked up from /tmp by examining your database ...
No; dummy has a buildroot and contains only an ordinary /tmp/XXX file.
Ooops, yes. Sorry for the FUD. Back to debugging ...
Problem reproduced, verify is failing on the Group index. Changing the spec file to have, for example, Group: User Interface/X causes the problem to disappear (but make sure you do a rpm --rebuilddb before trying to reproduce). So there appears to be a problem with verifying of an index that has duplicated entries (from the --force) when the last element is removed.
This defect is considered SHOULD-FIX for Fairfax.
Problem does not happen if the --force install is not performed. Tracing the database operations indicates that the operation is a delete followed by an add for the same hash key not verifying. Feels like a db3 problem, dunno whether it's with the del/put or the verify. I say the impact of this is minor (read: don't use --force) and the workaround with --rebuilddb is acceptable, and the likelihood of a delete of the last key followed by an add is small.
Ouch, this problem is much more severe than I thought. Try doing rpm --rebuilddb three times ...
... and my database is truncated severely. Appears to be a problem with my local build, not the distributed pron package. Grrr...
Fixed (by disabling the verify error message) in rpm-4.0.3-0.91.
*** Bug 59102 has been marked as a duplicate of this bug. ***
Fixed (again) by reapplying a sleepycat patch to db-4.0.14 in rpm-4.0.4.
The bug is back ... [root@pikachu tmp]# rpm -Fvh hwdata-0.5-1.noarch.rpm gtkam-* rawhide-release-20020307-1.noarch.rpm Preparing... ########################################### [100%] 1:gtkam ########################################### [ 25%] 2:hwdata ########################################### [ 50%] 3:gtkam-gimp ########################################### [ 75%] 4:rawhide-release ########################################### [100%] rpmdb: Suspiciously high nelem of 4294967295 on page 0 error: db4 error(-30979) from db->verify: DB_VERIFY_BAD: Database verification failed [root@pikachu tmp]# rpm -q rpm db4 rpm-4.0.4-7x.4 db4-4.0.14-4
A note: avoiding --force isn't really an option when working with Raw Hide ;o) The latest culprit is the "automake15" package ...