User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0 Build Identifier: Ran dnf update 6/14, the following errors were listed in the output: Cleanup : libdb-devel-5.3.28-16.fc25.x86_64 80/116 error: db5 error(-30969) from dbenv->open: BDB0091 DB_VERSION_MISMATCH: Database environment version mismatch error: cannot open Packages index using db5 - (-30969) error: cannot open Packages database in /var/lib/rpm error: db5 error(-30969) from dbenv->open: BDB0091 DB_VERSION_MISMATCH: Database environment version mismatch error: cannot open Packages index using db5 - (-30969) error: cannot open Packages database in /var/lib/rpm error: db5 error(-30969) from dbenv->open: BDB0091 DB_VERSION_MISMATCH: Database environment version mismatch error: cannot open Packages index using db5 - (-30969) error: cannot open Packages database in /var/lib/rpm error: db5 error(-30969) from dbenv->open: BDB0091 DB_VERSION_MISMATCH: Database environment version mismatch error: cannot open Packages index using db5 - (-30969) error: cannot open Packages database in /var/lib/rpm error: db5 error(-30969) from dbenv->open: BDB0091 DB_VERSION_MISMATCH: Database environment version mismatch error: cannot open Packages index using db5 - (-30969) error: cannot open Packages database in /var/lib/rpm error: db5 error(-30969) from dbenv->open: BDB0091 DB_VERSION_MISMATCH: Database environment version mismatch error: cannot open Packages index using db5 - (-30969) error: cannot open Packages database in /var/lib/rpm error: db5 error(-30969) from dbenv->open: BDB0091 DB_VERSION_MISMATCH: Database environment version mismatch error: cannot open Packages index using db5 - (-30969) error: cannot open Packages database in /var/lib/rpm error: db5 error(-30969) from dbenv->open: BDB0091 DB_VERSION_MISMATCH: Database environment version mismatch error: cannot open Packages index using db5 - (-30969) error: cannot open Packages database in /var/lib/rpm Cleanup : glibc-2.24-4.fc25.x86_64 116/116 ^Cwarning: %triggerin(man-db-2.7.5-3.fc25.x86_64) scriptlet failed, signal 2 Traceback (most recent call last): File "/usr/lib/python3.5/site-packages/dnf/yum/rpmtrans.py", line 427, in callback self._scriptError(bytes, total, h) File "/usr/lib/python3.5/site-packages/dnf/yum/rpmtrans.py", line 557, in _scriptError pkg, _, _ = self._extract_cbkey(h) File "/usr/lib/python3.5/site-packages/dnf/yum/rpmtrans.py", line 229, in _extract_cbkey return self._extract_str_cbkey(cbkey) File "/usr/lib/python3.5/site-packages/dnf/yum/rpmtrans.py", line 237, in _extract_str_cbkey assert(isinstance(name, basestring)) AssertionError FATAL ERROR: python callback ??? failed, aborting! Reproducible: Didn't try This was run on my test email server, I am of course holding off on running on my production. Both are Fedora 25, very vanilla builds, minimum software, using Postfix, Dovecot, I am not using any database software.
DB_VERSION_MISMATCH errors are expected as you have updated to a newer version of libdb which needs its old environment (internal data structures) to be rebuilt. This is done automatically if there is no other thread of control accessing the environment. Unfortunately during rpm scriplets calling rpm commands this cannot be done as the environment is still in use by rpm so instead libdb fails with proper error. The python fail in the triggerin scriplet seems unrelated to libdb. But, if you are able to reproduce, try running the dnf command with the "--rpmverbosity debug" argument to provide more information.
I just ran (6/22) dnf update on my production Fedora 25, which is a clone of the test machine on which the errors reported occured, at same update levels. I got the same DB_VERSION_MISMATCH errors, which as I understand you are saying are benign. I did not get the python3.5 errors at the end as reported. I did note a couple of messages: Cleanup : glibc-2.24-4.fc25.x86_64 234/234 /bin/dracut: line 634: warning: setlocale: LC_MESSAGES: cannot change locale (en_US.UTF-8): No such file or directory /bin/dracut: line 635: warning: setlocale: LC_CTYPE: cannot change locale (en_US.UTF-8): No such file or directory which again I suspect are benign. Otherwise, the updates appeared to install OK, and system appears running OK. Thanks,
The local errors in my comment 2 on 6/22/2017 turned out to indicate an error that began occurring after running latest updates. The local definitions apparently were negatively impacted. I was getting messages like this: -bash: warning: setlocale: LC_CTYPE: cannot change locale (en_US.UTF-8): No such file or directory -bash: warning: setlocale: LC_COLLATE: cannot change locale (en_US.UTF-8): No such file or directory -bash: warning: setlocale: LC_MESSAGES: cannot change locale (en_US.UTF-8): No such file or directory -bash: warning: setlocale: LC_NUMERIC: cannot change locale (en_US.UTF-8): No such file or directory -bash: warning: setlocale: LC_TIME: cannot change locale (en_US.UTF-8): No such file or directory [root@mail: ~]# ^C [root@mail: ~]# localectl System Locale: LANG=en_US.UTF-8 VC Keymap: us X11 Layout: us [root@mail: ~]# locale locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory I found reference to and ran the following command: /usr/sbin/build-locale-archive This appears to have fixed the problem, when I run locale command it now lists local definitions, and not just the basic fall back Posix shortlist it was showing before this error started occurring. So my question is, was there an error in the glibc update? Do I need to reinstall glibc-common, as the same source suggesting running the above command suggested?
In addition to the locale error above, I discovered that apparently the locale problem had stopped my postfix service from running, and disabled start on boot, I had to systemctl enable postfix, systemctl start postfix. Now it is starting on boot again.
Changing the component to glibc as the issue Ron is facing now does not seem connected to libdb anymore.
(In reply to Ron Edge from comment #3) > So my question is, was there an error in the glibc update? Do I need to > reinstall glibc-common, as the same source suggesting running the above > command suggested? Would you please check which glibc-langpack packages were installed before and after the update? It should be possible to obtain this information from the /var/log/dnf.rpm.log files.
Happened to me right now: ~]$ sudo dnf update error: db5 error(-30969) from dbenv->open: BDB0091 DB_VERSION_MISMATCH: Database environment version mismatch error: cannot open Packages index using db5 - (-30969) error: cannot open Packages database in /var/lib/rpm Error: Error: rpmdb open failed
[xx@xx ~]$ sudo dnf clean dbcache 43 files removed [xx@xx ~]$ sudo dnf update Last metadata expiration check: 0:11:08 ago on Wed Jul 12 21:32:22 2017. Dependencies resolved. Nothing to do. Complete! sudo dnf clean dbcache seems to have fixed it, assuming there really are no updates since last night.
See bug 1483553 for a related issue.