Bug 567709

Summary: rpmdb version mismatch?
Product: [Fedora] Fedora Reporter: Lennart Poettering <lpoetter>
Component: yumAssignee: Seth Vidal <skvidal>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: ffesti, james.antill, maxamillion, pmatilai, tim.lauridsen
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: yum-3.2.28-3.fc14 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-04-29 16:15:58 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:

Description Lennart Poettering 2010-02-23 18:00:18 UTC
I upgraded to current rawhide and now yum refuses to work:

$ sudo yum install fedora-release-rawhide
rpmdb: Build signature doesn't match environment
error: db3 error(-30971) from dbenv->open: DB_VERSION_MISMATCH: Database environment version mismatch
error: cannot open Packages index using db3 -  (-30971)
error: cannot open Packages database in /var/lib/rpm
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in <module>
    yummain.user_main(sys.argv[1:], exit_code=True)
  File "/usr/share/yum-cli/yummain.py", line 254, in user_main
    errcode = main(args)
  File "/usr/share/yum-cli/yummain.py", line 88, in main
    base.getOptionsConfig(args)
  File "/usr/share/yum-cli/cli.py", line 191, in getOptionsConfig
    self.conf
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 774, in <lambda>
    conf = property(fget=lambda self: self._getConfig(),
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 255, in _getConfig
    startupconf = config.readStartupConfig(fn, root)
  File "/usr/lib/python2.6/site-packages/yum/config.py", line 834, in readStartupConfig
    startupconf.releasever = _getsysver(startupconf.installroot, startupconf.distroverpkg)
  File "/usr/lib/python2.6/site-packages/yum/config.py", line 944, in _getsysver
    idx = ts.dbMatch('provides', distroverpkg)
_rpm.error: rpmdb open failed

yum-3.2.26-4.fc14.noarch
rpm-4.8.0-10.fc13.i686

rpm commands seem to work well still.

Comment 1 seth vidal 2010-02-23 19:19:04 UTC
rpm -q rpm-python python

I suspect you have an old or damaged rpm-python

Comment 2 Lennart Poettering 2010-02-23 22:41:25 UTC
Downgrading to yum-3.2.26-4.fc13.noarch (i.e. fc14 → fc13) fixed things for me.

Comment 3 seth vidal 2010-02-23 23:29:20 UTC
3.2.26-4.fc13 and 3.2.26-4.fc14 are, for yum, code identical.

Now - I'm not sure which version of python might be in rawhide as opposed to fc13 but there is no change in yum, at all.

Comment 4 Lennart Poettering 2010-02-24 00:00:21 UTC
But this is the one thing I did to make it work again, really. Because I couldn't use yum I downloaded the fc13 rpm from koji and installed it with rpm -Uvh --force.

Since then I have also downgraded the rest of the fc14 packages I had. But the one thing that made yum work again was downgrading that single package.

Comment 5 seth vidal 2010-02-24 02:23:29 UTC
if you can recreate this by reinstalling the fc14 pkg I'd be interested to hear - but there shouldn't be anything in the yum pkg which changes.

Comment 6 James Antill 2010-04-29 16:15:58 UTC
 I guess rpm changed the error it throws, so I added this upstream:

commit cfa592298e2fa3afbb9f61c697b8498ec758d03b
Author: James Antill <james>
Date:   Thu Apr 29 12:14:32 2010 -0400

    Add the new, 4.8.0, error class for "cannot open DB", BZ 567709

diff --git a/yum/config.py b/yum/config.py
index 1b78fcd..3610b91 100644
--- a/yum/config.py
+++ b/yum/config.py
@@ -1000,6 +1000,9 @@ def _getsysver(installroot, distroverpkg):
             else:
                 raise Errors.YumBaseError("Error: " + str(e))
         raise Errors.YumBaseError("Error: " + str(e))
+    except rpm.error, e:
+        # This is the "new" code for "cannot open rpmdb", 4.8.0 ish
+        raise Errors.YumBaseError("Error: " + str(e))
     # we're going to take the first one - if there is more than one of these
     # then the user needs a beating
     if idx.count() == 0:

...it won't "fix" the underlying problem, but you should get a nicer msg.

Comment 7 Fedora Update System 2010-08-02 14:11:36 UTC
yum-3.2.28-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/yum-3.2.28-1.fc13

Comment 8 Fedora Update System 2010-08-02 14:13:07 UTC
yum-3.2.28-1.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/yum-3.2.28-1.fc14

Comment 9 Fedora Update System 2010-08-02 14:14:42 UTC
yum-3.2.28-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/yum-3.2.28-1.fc12

Comment 10 Fedora Update System 2010-08-05 23:44:42 UTC
yum-3.2.28-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 11 Fedora Update System 2010-08-12 20:15:38 UTC
yum-3.2.28-3.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/yum-3.2.28-3.fc12

Comment 12 Fedora Update System 2010-08-12 20:18:05 UTC
yum-3.2.28-3.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/yum-3.2.28-3.fc13

Comment 13 Fedora Update System 2010-08-12 20:20:30 UTC
yum-3.2.28-3.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/yum-3.2.28-3.fc14

Comment 14 Fedora Update System 2010-08-17 05:45:49 UTC
yum-3.2.28-3.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 15 Fedora Update System 2010-08-20 02:19:29 UTC
yum-3.2.28-3.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 16 Fedora Update System 2010-08-24 01:37:08 UTC
yum-3.2.28-3.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.