If you encounter any of the following messages: rpmdb: PANIC: fatal region error detected; run recovery error: db3 error(22) from dbenv->open: Invalid argument error: cannot open Packages index using db3 – Invalid argument (22) error: cannot open Packages database in /var/lib/rpm error: rpmdb: damaged header #1439 retrieved — skipping. or a similar RPM-related error message, it is probable that your RPM database is damaged. RPM uses a database to maintain the package dependency information. This database is normally located at /var/lib/rpm. # cd /var/lib/rpm # ls -al total 86420 drwxr-xr-x. 2 root root 4096 Nov 18 21:09 . drwxr-xr-x. 45
Project Atomic, a Red Hat sponsored project, features an interesting new update system for RPM-based Linux operating systems called OSTree (rpm-ostree) which has been developed by Colin Walters over the last couple of years. Evidently OSTree supports atomic updates to an OS although I am not sure how that actually works because there is a lot of marketing hype and buzz words associated with Project Atomic including Docker containers. In the default model, the RPMs are composed on a server into an OSTree repository, and client systems can replicate in an image-like fashion, including incremental updates. However, unlike traditional Linus
In previous posts I examined the internals of RPM packages and the RPM database itself. In this post, I explore how to trace RPM package installation, update and removal on Linux distributions which use YUM (YellowDog Update Modified). If you examine /var/log/yum.log, an example of which is shown below, you will note that the date component of each entry includes the day and month but not the year. Feb 15 10:00:44 Updated: ibus-1.5.5-1.fc20.x86_64 Feb 15 10:00:45 Updated: ibus-gtk2-1.5.5-1.fc20.x86_64 Feb 15 10:00:47 Updated: python-boto-2.23.0-1.fc20.noarch Feb 15 10:00:48 Installed: python-dropbox-1.6-4.fc20.noarch Feb 15 10:00:56 Installed: python-crypto-2.6.1-1.fc20.x86_64 Feb 15 10:00:57 Installed: python-paramiko-1.10.1-2.fc20.noarch Feb 15
A couple of months ago, the PackageKit utility on my Fedora 18 system stopped working. YUM continued to work so I had an easy workaround and did not really try to trace down the problem and fix it. I assumed that a future version of a PackageKit RPM would fix the problem. Recently I did a FedUp upgrade to Fedora 19 and the problem persisted so I decided the time had come to investigate the root cause of the problem and fix it. Here is how the problem manifested itself: A quick check of Fedora Bugzilla convinced me that the
The latest version of RPM (4.10) that was recently released supports dpkg-style tildes (~) in version/release strings. The tilde character can be used to append a label such as “beta” to a package without actually incrementing the version of the package. For example – package-1.0~beta. In this case, the package package-1.0~beta would not replace package-1.0 as the former package is considered to be an older version, even if it was released later. See here for more information.