Translate

Image of Linux Kernel Development (3rd Edition)
Image of Android Wireless Application Development
Image of Modern Operating Systems (3rd Edition)
Image of Beginning Google Maps API 3

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

OSTree

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 this post, I explore how to use the YUM history database to trace the timeline (installation, updates and removal) of RPM packages on modern RPM-based Linux distributions.

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.