Translate

Image of Android Wireless Application Development
Image of RHCE Red Hat Certified Engineer Linux Study Guide (Exam RH302) (Certification Press)
Image of Operating System Concepts
Image of XSLT 2.0 and XPath 2.0 Programmer's Reference (Programmer to Programmer)

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.