Home Linux troubleshooting How To Solve “Error: rpmdb open failed” Error In CentOS

How To Solve “Error: rpmdb open failed” Error In CentOS

By sk
Published: Last Updated on 52.9K views

Today, I was testing Nginx web server in a CentOS 7 VM. Unfortunately, the power has gone in the middle of the update process. Since I don't have a UPS, my host system went down immediately. After few minutes, the power came, and I turned on the VM again and started the upgrade process. When I run the "yum update" command, I got this error message:

error: rpmdb: BDB0113 Thread/process 2196/139984719730496 failed: BDB1507 Thread died in Berkeley DB library
error: db5 error(-30973) from dbenv->failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
error: cannot open Packages index using db5 - (-30973)
error: cannot open Packages database in /var/lib/rpm

Error: rpmdb open failed

It seemes like YUM broke down. I couldn't run any yum command. I haven't faced this error before, and I didn't know what to do. So, I headed over to the CentOS forum hoping to find a suitable solution to fix this issue. After a few searches over the forum, luckily I found a workaround. If you ever got into this problem, look nowhere and just do the following steps.

First backup the rpm database using command as root user:

# mv /var/lib/rpm/__db* /tmp

Then, run the following command:

# yum clean all

Now, run the update again:

# yum update
Loaded plugins: fastestmirror
Cleaning repos: base epel extras updates
Cleaning up everything
Cleaning up list of fastest mirrors
[root@server ~]# yum update
Loaded plugins: fastestmirror
base | 3.6 kB 00:00 
epel/x86_64/metalink | 5.0 kB 00:00 
epel | 4.3 kB 00:00 
extras | 3.4 kB 00:00 
updates | 3.4 kB 00:00 
(1/7): base/7/x86_64/group_gz | 155 kB 00:02 
(2/7): epel/x86_64/group_gz | 170 kB 00:04 
(3/7): extras/7/x86_64/primary_db | 191 kB 00:12 
(4/7): epel/x86_64/updateinfo | 809 kB 00:21 
(5/7): base/7/x86_64/primary_db | 5.6 MB 00:26 
(6/7): epel/x86_64/primary_db | 4.8 MB 00:46 
(7/7): updates/7/x86_64/primary_db | 7.8 MB 00:50 
Determining fastest mirrors
 * base: mirror.ehost.vn
 * epel: repo.ugm.ac.id
 * extras: mirror.ehost.vn
 * updates: mirror.dhakacom.com
Resolving Dependencies
--> Running transaction check
---> Package NetworkManager.x86_64 1:1.4.0-19.el7_3 will be updated
---> Package NetworkManager.x86_64 1:1.4.0-20.el7_3 will be an update
---> Package NetworkManager-adsl.x86_64 1:1.4.0-19.el7_3 will be updated
--> Finished Dependency Resolution

Dependencies Resolved

 Package Arch Version Repository Size
 kernel x86_64 3.10.0-514.26.2.el7 updates 37 M
 python2-libcomps x86_64 0.1.8-3.el7 epel 46 k
 replacing python-libcomps.x86_64 0.1.6-13.el7
 NetworkManager x86_64 1:1.4.0-20.el7_3 updates 2.5 M
 NetworkManager-adsl x86_64 1:1.4.0-20.el7_3 updates 146 k
 NetworkManager-bluetooth x86_64 1:1.4.0-20.el7_3 updates 165 k
 NetworkManager-glib x86_64 1:1.4.0-20.el7_3 updates 385 k
 NetworkManager-libnm x86_64 1:1.4.0-20.el7_3 updates 443 k
 NetworkManager-team x86_64 1:1.4.0-20.el7_3 updates 147 k
 python-perf x86_64 3.10.0-514.26.2.el7 updates 4.0 M
 sudo x86_64 1.8.6p7-23.el7_3 updates 735 k
 systemd x86_64 219-30.el7_3.9 updates 5.2 M
 systemd-libs x86_64 219-30.el7_3.9 updates 369 k
 systemd-sysv x86_64 219-30.el7_3.9 updates 64 k
 tuned noarch 2.7.1-3.el7_3.2 updates 210 k
 xfsprogs x86_64 4.5.0-10.el7_3 updates 895 k
 kernel x86_64 3.10.0-123.el7 @anaconda 127 M

Transaction Summary
Install 2 Packages
Upgrade 46 Packages
Remove 1 Package

Total download size: 84 M
Is this ok [y/d/N]: y

I type y to continue the update. Voila! Everything is worked as expected.

Finally, I cleaned the backup using command:

# rm -i /tmp/__db*

And, that's all for now. Hope this helps.

Related read:

You May Also Like


k3p3 September 11, 2018 - 9:06 am

Thank You.. It works

vicky August 16, 2022 - 9:59 pm

rm -f /var/lib/rpm/__db*
db_verify /var/lib/rpm/Packages
rpm –rebuilddb
yum clean all

Marcos September 16, 2018 - 10:18 pm

Thank You!!!

blah September 21, 2018 - 11:40 am


Nikhil Madhwani October 5, 2018 - 2:56 am

Thank you!!!

Rob November 2, 2018 - 8:58 am

Thanks, first link I look into and it worked!

tomaski December 7, 2018 - 4:04 am

yeah, it does help, but in my case the issue just keeps returning… ¯\_(ツ)_/¯

James February 16, 2019 - 3:47 am

Praise you!

sk February 16, 2019 - 12:22 pm

My pleasure.

robustrockster July 24, 2019 - 4:18 pm

thanks it worked for me.
thanks indeed

sk July 24, 2019 - 6:24 pm

You’re welcome. Glad it helped.

nabor September 16, 2019 - 3:02 am

It works like charm! Thank you!

icycle September 27, 2019 - 4:16 am

There’s another, simpler, solution that works for me:

rpm –rebuilddb

Yann December 6, 2019 - 4:20 pm

Thank you !!!!!!!!!!!!

Tanaji February 17, 2020 - 10:55 am

Thank you. Was able to resolve the issue.

Aitor February 24, 2020 - 4:22 pm

Thank you, it worked on centos with directadmin.

Xd March 20, 2020 - 11:32 am

Cool! Thank you

Muhammad Hafid March 27, 2020 - 7:10 am

Thanks my problem solved

Ingram Braun June 7, 2020 - 11:57 am

Works like a charm! Thank you!

maub_dash July 9, 2020 - 7:53 pm


PK January 3, 2021 - 9:37 am

Trying this with DNF now. It does NOT work. “DNF update” cannot even connect to some servers, and basic commands like sudo are missing. What’s happening?

MarkAnthony January 7, 2021 - 4:56 pm

rpm –rebuilddb was fast and worked for me.

seems wise though to make note of both methods described here

thanks for this discussion

Saadedin June 2, 2021 - 8:06 am

Works like a charm! Thank you!

DevOps September 23, 2021 - 6:36 pm

Thank you, it working for me

Danny Lopez September 21, 2022 - 7:58 pm

thanks, it Work


Leave a Comment

* By using this form you agree with the storage and handling of your data by this website.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

This website uses cookies to improve your experience. By using this site, we will assume that you're OK with it. Accept Read More