[CentOS] Rebuilding corrupted RPM database on CentOS

Justina

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:

• third-party software;
• incomplete transactions that were done previously;
• network failures during packet upgrades;
• removal of certain packets.

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.

WARNING

CentOS 7 reached the EOL June 30, 2024:

https://blog.centos.org/2023/04/end-dates-are-coming-for-centos-stream-8-and-centos-linux-7/

Because of this, you may encounter some repository issues. We recommend that you reinstall another OS that has not yet reached EOL.

If you are using CentOS 7 and encounter a mirror issue, please check out this guide to resolve the problem.

Symptoms of 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.

Solutions

Method #1

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

Method #2

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.

Method #3

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

Using dcrpm to identify and correct RPM database

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:

# dcrpm

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.