dnf broke fedora 25 after crash during update

[srakitnican]

so dnf and yum both removed, manually reinstalling them to try get system going again is going to be more work than just reinstalling

thanks again for all the help!

daniel

Just a little correction, it should not actually remove dnf or yum, just "ghost" packages. But I respect your decision, it is a though situation for someone that is not very familiar with the system.

[lsatenstein]

TODAY JUNE 21, at 10:45EST (GMT-4)

system-python: /builddir/build/BUILD/hawkey-0.6.4/src/sack.c:354: load_ext: Assertion `ret == 0' failed.

DNF is not working and the rpm --rebuilddb does not correct this problem

Can/should I use

dnf remove $(dnf repoquery --duplicated --latest-limit -1 -q) hawkey-0.6.4

[bloodnok]

This worked for me ... (although on a second machine I had to do it twice ,,,)

# dnf clean all
# dnf --disablerepo=updates update
# dnf update

[abentley]

I have gotten that problem many times over the yrs w/Fedora, got it again w/25. Solution = comment out the #metalink and uncomment the baseurl in fedora.repo and/OR fedora-updates.repo

[antikythera]

I've no idea what 's been going on with the update servers regarding dnf package information since I've been out of action most of the day. yum-deprecated from raveit65's copr still works okay this evening.

I still don't use dnf for bare metal installs as I find the old yum-deprecated and yumex packages more reliable. granted dnf is a little faster (not that much in it though really) and far less problematic than when I posted the setup guide last October but you still get these hiccups.

yum is still used for RHEL and CentOS 7.3 as the default package manager if you do a minimal install. so it should have a few years in it yet for fedora libraries permitting.

[al_chem]

Regarding today's issue with updates and bug #1463561:

There was a glitch on the main update server and the file that contained all the update information got replaced with one containing garbage (not quite, but that was the gist of it).
The problematic files propagated into local mirrors (where people connect to and get their updates).
As dnf didn't produce any meaningful messages for that type of error, it took a while to locate the problem.
Both issues have been dealt with.

Do keep in mind, that mirrors retrieve the file lists every x hours (depending on admin's settings) and that metadata are also cached locally on end systems. This means that even if you remove the stale metadata (e.g. with dnf clean all), you might hit a mirror that has not yet retrieved the proper file list, which will result in the same error. Just be patient, and the issue will go away.

This has absolutely nothing to do with the libdb problem and you do not need to rebuild the rpm database. You need to do that only if you have just updated to libdb-5.3.28-21.