PSA: Errors after updating libdb

This is an important public service announcement for Fedora 24, 25 and 26 (pre-release) users, courtesy of the Fedora QA team.

The short version

If you recently updated and got some kind of error or crash, and now you’re getting RPM database errors, try this command to fix it (you can use sudo for root privileges):

sudo rpm --rebuilddb

If that’s not enough, try:

sudo rm -f /var/lib/rpm/__db*
sudo rpm --rebuilddb
sudo restorecon -RFv /var/lib/rpm

Now all should be well again. We do apologize for this. Note that if you’re unlucky and have the updates-testing repository enabled, there’s a chance you may run into issues with more than one update: the same recovery steps should work each time.

The longer version

There’s a rather subtle and tricky bug in libdb (the database that RPM uses) which has been causing problems with upgrades from Fedora 24/25 to Fedora 26. The developers have made a few attempts to fix this, and testing this week had indicated that the most recent attempt — libdb-5.3.28-21 — was working well. We believed the fix needed to be applied both on the ‘from’ and the ‘to’ end of any affected transaction, so we went ahead and sent the -21 update out to Fedora 24, 25 and 26.

Unfortunately it turns out that updating to -21 along with other packages can possibly result in a crash at the very end of the process, which in turn causes a (as it happens, minor and fully recoverable) problem in the RPM database.

We initially sent a -22 update to updates-testing which reverts the changes from -21, but then found out that updating from -21 to -22 causes a similar result. At that point we decided it was probably best just to cut our losses, stick with -21, and document the issues for anyone who encountered them, and we have removed the -22 update from updates-testing again. There has since been a -23 build soon which restores the fixes from -21 and adds another upgrade-related fix.

So if you’re affected by RPM database issues with any libdb update, just doing the old “rebuild the RPM database” trick will resolve the problem:

sudo rm -f /var/lib/rpm/__db*
sudo rpm --rebuilddb

It seems that rebuilding the RPM database can give the files the wrong SELinux label (see bug #1461313), so you should also run:

sudo restorecon -RFv /var/lib/rpm

After the database rebuild, to ensure the labels are corrected. If you did wind up on -22, you may also want to update to -23. Note that you may need to do the rebuilddb steps again after upgrading from -22 to -23.

It’s unfortunate that we have to break that one out of cold storage, but it should at least get you back up and working for now. We do apologize sincerely for this mess, and we’ll try and do all we can to fix it up ASAP.

Fedora Project community Using Software

9 Comments

  1. Saurav Sengupta

    I did get an error some days ago, causing an entire set of upgrades to fail like dominoes, and moved away from Fedora simply because I didn’t know about rebuilding the RPM database(!), though I’m not sure whether the failure was caused by this. However, coming back to F26 now, I see that libdb is at -21 at the moment, and I haven’t faced any RPM issues yet.

    Another critical issue had occurred some time ago when CUPS would not start at boot time: https://bugzilla.redhat.com/show_bug.cgi?id=1437065.

    I do wish that Fedora would adopt a more conservative policy for upgrades to critical system packages. This should not be too difficult, since the updates-testing repository is already in place – upgrades for such packages need not be pushed to the regular updates repository too quickly. Users who want to/can test such upgrades may simply install them from updates-testing.

    • kallisti5

      I actually perfer the rapid up-to-date packages on Fedora. If you want long-term-slow stable, might want to look at CentOS.

      • Saurav Sengupta

        Yes, I know about CentOS, but I didn’t mean that slow. 😉 I just wished the system-critical upgrades would slow down a bit. That said, I too like the quick updates to applications and desktop environments provided in Fedora. Cheers to that!

    • Hi Saurav! Sorry for the trouble. This update was a special case because it was actually considered a blocker for Fedora 26 Beta: the problem we were trying to solve was that in some circumstances, upgrades to Fedora 26 would hang, and it was necessary to update libdb in Fedora 24 and Fedora 25 to fully solve this. That meant that the updates had to go out to Fedora 24 and Fedora 25 before the Fedora 26 Beta release date, so they couldn’t sit in updates-testing as long as we’d have liked.

      In addition to that that it seems there was some kind of unfortunate Bodhi malfunction – someone tried to push the -21 updates back to updates-testing early last week and I assumed that had worked, but when I went back and looked over the sequence of events later, it seems like that request was never actually honoured, and the packages weren’t queued for updates-testing until much later in the week. I’m not quite sure why that went wrong, yet, but we’ll look into it.

      • Saurav Sengupta

        Thanks for the clarification, Adam. Hope upgrades go more smoothly in future! 🙂

  2. Murali

    I faced issues relating to dnf update/install with an error ” Failed to synchronize cache for repo ‘fedora’ ” and I did the upgrade to Fedora 26 and initially it did restore proper functioning of dnf update command. However, dnf update /install returns the same error now. I tried rpm –rebuildb but no change. My kernel version is 4.11.4-300.fc26.x86_64 and any help is welcome to fix this issue.

    • Hi Murali! That’s a different error, not related to the RPM database. If anything it suggests you might have some kind of problem with network connectivity. If you can’t solve it, try asking in #fedora on Freenode IRC, or on the Fedora forums, or on Ask Fedora.

    • Saurav Sengupta

      Your Internet connection may be faulty, as mentioned by Adam. Try with a different​ Internet connection. You could also try deleting the file ‘/etc/dnf/dnf.conf’ and then try again.

    • Saurav Sengupta

      Back up /etc/dnf/dnf.conf first, if you plan to delete it. Restore it if it doesn’t work or makes no difference. The simplest way is to rename it instead of deleting it. There are more settings available for DNF’s network connectivity about which you can ask on the channels mentioned by Adam.

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions