Image of Operating System Concepts
Image of Modern Operating Systems (3rd Edition)
Image of XSLT 2.0 and XPath 2.0 Programmer's Reference (Programmer to Programmer)
Image of Advanced Programming in the UNIX Environment, Second Edition (Addison-Wesley Professional Computing Series)

Repair Damaged RPM Database

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

YUM Package Installation Updating and Removal Forensics

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

Fedora 18/19, PackageKit, KSplice and Failed Backend Message

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

Tilde Support Added to RPM 4.10

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.