RH342 - ch06s03

Red Hat Enterprise Linux 8 uses yum or rpm to install and remove packages. A Berkeley DB embedded database library manages the RPM package and transaction data that are stored in the /var/lib/rpm/ directory. This directory contains all the files that make up the RPM database, plus additional __db.* index files.

Although RPM database corruption is uncommon, a damaged database will block your ability to manage packages or to install RPM-based software. This section discusses procedures for repairing a corrupted RPM database.

Cleaning Stale Lock Files

The RPM database allows multiple processes to read and write to the database concurrently, which can make it difficult to identify and remove stale database locks. Typically, stale locks are left behind by abnormal process termination from a kernel crash, a kill command, or a loss of system power. Two methods are available to clean stale lock files.

The recommended method is to reboot the system. Rebooting removes the locks during the sysinit portion of the boot, when the system is assured that no other process has a lock on the RPM database.
If rebooting does not resolve the issue, then manually remove all lock files and the RPM database index files.
1. Delete all files in the /var/spool/up2date directory.
```
[root@host ~]# cd /var/spool/up2date
[root@host ~]# rm *
[root@host ~]# rm .*
```
2. Verify that no processes with open RPM database files are running.
```
[root@host ~]# ps -aux | grep -e rpm -e yum -e up2date
[root@host ~]# lsof | grep /var/lib/rpm
```
3. If no RPM database process is running, then you can safely delete the database index files.
```
[root@host ~]# rm /var/lib/rpm/__db*
...output omitted...
```

Recovering Corrupted RPM Database

RPM database corruption might persist after removing lock files. Recovering the RPM database might require rebuilding the package metadata files in the /var/lib/rpm/ directory. Rebuilding the metadata files also requires reconstructing the database indexes. The method for recovering the corrupted RPM database starts with copying the files so that the recovery procedure can be repeated if necessary.

Back up the existing database.

[root@host ~]# tar cjvf rpmdb-$(date +%Y%m%d-%H%M).tar.bz2 /var/lib/rpm
tar: Removing leading `/' from member names
/var/lib/rpm/
/var/lib/rpm/Requirename
/var/lib/rpm/Name
/var/lib/rpm/Basenames
/var/lib/rpm/Group
/var/lib/rpm/Packages
/var/lib/rpm/.dbenv.lock
/var/lib/rpm/Providename
/var/lib/rpm/Conflictname
/var/lib/rpm/Obsoletename
/var/lib/rpm/Triggername
/var/lib/rpm/Dirnames
/var/lib/rpm/Installtid
/var/lib/rpm/Sigmd5
/var/lib/rpm/Sha1header
/var/lib/rpm/Filetriggername
/var/lib/rpm/Transfiletriggername
/var/lib/rpm/Recommendname
/var/lib/rpm/Suggestname
/var/lib/rpm/Supplementname
/var/lib/rpm/Enhancename
/var/lib/rpm/.rpm.lock
/var/lib/rpm/db.001
/var/lib/rpm/db.002
/var/lib/rpm/__db.003

Verify RPM database integrity by verifying the critical Packages file.

[root@host ~]# cd /var/lib/rpm
[root@host rpm]# /usr/lib/rpm/rpmdb_verify Packages
...output omitted...
BDB5105 Verification of Packages failed.

If the verification fails or displays errors, then rebuild the Packages file by dumping from the current file and reloading the good packages from the dump output stream into a new file. In this example, Packages is first renamed to Packages.bad, so that rpmdb_load can create a file with the default Packages name. Corrupted or incomplete packages are skipped and not reloaded.
```
[root@host rpm]# mv Packages Packages.bad
[root@host rpm]# /usr/lib/rpm/rpmdb_dump Packages.bad | /usr/lib/rpm/rpmdb_load Packages
[root@host rpm]# /usr/lib/rpm/rpmdb_verify Packages
BDB5105 Verification of Packages succeeded.
```
Use the package metadata from the newly built Packages file to rebuild the RPM database indexes.
```
[root@host rpm]# rpm -v --rebuilddb
...output omitted...
```

Verify that the RPM database is successfully rebuilt.

[root@host rpm]# /usr/lib/rpm/rpmdb_verify Packages
BDB5105 Verification of Packages succeeded.

Additional RPM operations should no longer cause error messages.

If the restored RPM database has fewer than all of the original packages, then view /var/log/yum.log to identify the missing packages. Then, use the rpm --justdb command to add the missing packages to the RPM database without changing or reinstalling files on the host file system.

References

rpm(8) man page

For further information, refer to How to rebuild RPM database on a Red Hat Enterprise Linux system? at https://access.redhat.com/solutions/6903

Discuss Red Hat Enterprise Linux Diagnostics and Troubleshooting

Go to community

Welcome to the Red Hat Enterprise Linux Diagnostics and Troubleshooting (RH342) group!

cschunke

26 wrz 2023

We are excited to launch a space dedicated to the Red Hat Training course Red Hat Enterprise Linux Diagnostics and Troubleshooting! To gain the most value from this group - click the "Join Group" button in the upper right hand corner of the group home page.We encourage group members to collaborate in this group to discuss topics, ask questions, share best practices and tips, provide course feedback, and share their accomplishments as it relates to RH342.Read more about Red Hat Enterprise Linux Diagnostics and Troubleshooting here.

445

Revision: rh342-8.4-6dd89bd

Click Create to build all of the virtual machines needed for the classroom lab environment. This may take several minutes to complete. Once created the environment can then be stopped and restarted to pause your experience.
When a lab is created, click Start to run all of the virtual machines in the classroom.
Click Stop to stop all the virtual machines from running. This will not delete your lab.
If you Delete your lab, you will remove all of the virtual machines in your classroom and lose all of your progress.

Virtual machine actions

Click Start to power on the virtual machine.
Click Shutdown to gracefully shut down the virtual machine, preserving disk contents.
Click Power off to forcefully shut down the virtual machine, while still preserving disk contents.
Click Open console to connect to the system console of the virtual machine in a new browser.

Auto-stop timer

The Red Hat Learning Subscription entitles you to set allotment of lab time.
To help conserving your allotted time, the lab environment uses automatic timers to stop or destroy your lab environment when the timer expires.

Click the Auto-stop button [+] to extend the time you would like to spend with the labs.
Click the Auto-destroy button [+] to add day(s) to the auto-destroy timer.

Auto-stop has a maximum of 11 hours, and auto-destroy has a maximum of 14 days.
Be careful to keep the timers set while you are working, so that your environment doesn't shut down unexpectedly.
We also suggest not to set the auto-timers unnecessarily high, which could waste your lab time allotment