Segmentation faults with up2date/rpm

Had a nasty one tonight that I had to turn over to Paul. up2date was segfaulting on a RHEL3 server, along with some rpm queries, such as `rpm -qa’. I was able to narrow it down to a specific package, though that did not help at all. The rpm database had some severe corruption.

I removed the __db.00* files from /var/lib/rpm and rebuilt the database with rpm –rebuilddb; however, this did not resolve the issue. I attempted to recreate the database, by doing the following:

[code lang=”bash”]rpm -qa > rpm-list ; rpm –initdb ; cat rpm-list | while read line ; do rpm –nodeps –noscripts –notriggers –excludepath / $line ; done[/code]

However, the `rpm -qa’ hung, as noted earlier. Tough spot.

I had to move on, but Paul dove in. After a few hours of fitful hacking, he declared himself the winner — he had solved it. What did he do?

He removed all of the files in /var/lib/rpm except for Packages, then ran `rpm –rebuilddb’. The __db.00* files are just lock files, and while removing them can help, rpm transactions and queries still read all the other files and databases, thus rereading the corruption. Removing all the other databases (except the base Packages database) and then running a –rebuilddb operation actually rebuilds the databases… and the corruption cleared.

I also found this neat snippet to see if anything has a lock on the rpm databases:

[code lang=”bash”]cd /var/lib/rpm
/usr/lib/rpm/rpmdb_stat -Cl
[/code]

One Comments

  • E Off

    October 2, 2012

    Thank you very much for your post. I spent 4 months trying to rebuild a rpm database that resulted in seg faults.

    This is what fixed it for me:

    “Removing all the other databases (except the base Packages database) and then running a –rebuilddb operation actually rebuilds the databases… and the corruption cleared.”

Leave a Reply