It looks like you're new here. If you want to get involved, click one of these buttons!Sign In Register
It looks like you're new here. If you want to get involved, click one of these buttons!
The RPM database holds information about all the RPM packages installed on your CentOS server. It consists of files that are stored in /var/lib/rpm/ directory. It is used to apply updates to your system via the YUM package manager. However, the RPM database might be corrupted, causing issues to update packages or even being unable to run any rpm and yam commands.
RPM database might be corrupted due to various reasons. For example, this might be caused by:
These are just a few reasons, but there may be more. If you want what exactly corrupted the RPM database, you can try debugging it. In this tutorial, we will provide some ways to recover a corrupted RPM database.
When the RPM database becomes corrupted, you may receive the following or similar errors:
rpm command terminates with “cannot open Packages database in /var/lib/rpm”
rpmdb: Lock table is out of available locker entries
rpmdb: /var/lib/rpm/Packages: unexpected file type or format
error: cannot open Packages index using db3 – Invalid argument (22)
error: rpmdbNextIterator: skipping h# 1601 Header V4 RSA/SHA1 signature: BAD, key ID 2142eef7
rpmdb: BDB0113 Thread/process 4106/140140548798528 failed: BDB1507 Thread died in Berkeley DB library
This will most likely mean that the database is corrupted.
First, create a backup folder and copy the current RPM database:
# mkdir /var/lib/rpm/backup
# cp -a /var/lib/rpm/__db* /var/lib/rpm/backup/
Next, remove the old database:
# rm -f /var/lib/rpm/__db.[0-9][0-9]*
Print errors and then rebuild the database indices from the installed package headers:
# rpm --quiet -qa
# rpm –rebuilddb
Finally, remove all entries for currently enabled repositories from the cache:
# yum clean all
Backup your current RPM database:
# mkdir /backups/
# tar -zcvf /backups/rpmdb-$(date +"%d%m%Y").tar.gz /var/lib/rpm
Remove /var/lib/rpm/__db* file to prevent stale locks and verify the integrity of the master package metadata file /var/lib/rpm/Packages. By the way, this (/var/lib/rpm/Packages) is the file that needs to be rebuilt:
# rm -f /var/lib/rpm/__db*
# /usr/lib/rpm/rpmdb_verify /var/lib/rpm/Packages
In case these actions fail, you need to dump and load a new database (and verify the integrity of the freshly loaded Packages file):
# cd /var/lib/rpm/
# mv Packages Packages.back
# /usr/lib/rpm/rpmdb_dump Packages.back | /usr/lib/rpm/rpmdb_load Packages
# /usr/lib/rpm/rpmdb_verify Packages
Check database headers using the -q and -a flags. You can see errors sent to the stderror :
# rpm -qa >/dev/null #output is discarded to enable printing of errors only
Finally, you can rebuild the RPM database using -vv option that will display debugging information:
# rpm -vv –rebuilddb
To check this method in more detail, you can check the RMP database recovery page.
If the above methods did not work, you can try executing these commands:
# mv Packages Packages-BAKUP
# db_dump Packages-BAKUP | db_load Packages
# rpm -qa
# rpm –rebuilddb
There is a dcrpm (detect and correct rmp) command-line tool that you can use to deal with problems that occur with the RPM database. You can also run it regularly via cron.
You can download the tool by running:
# git clone https://github.com/facebookincubator/dcrpm.git
# cd dcrpm
# python setup.py install
To detect any outstanding issues with RPM on your server, simply run:
Before using one on your host, be sure to check its Github repository.
We thank our client in Toulupe, who suggested addressing RMP database issues in our community forum and also provided one of the solutions above.