Germán A. Racca writes:
> After the reboot, run
> rpm --rebuilddb
> to rebuild the rpm database. Afterwards, run rpm -V against the NEWER
> version of systemd and dnf packages. Only if rpm -V gives a clean bill
> of health would it be safe to forcefully remove the older versions from
> systemd and dnf.
Hi Sam, thanks for your message. After fsck and reboot, I did:
# rpm --rebuilddb
which finished without errors. Then I verified the versions of dnf:
# rpm -q dnf
and verified the newer version of the package:
# rpm -V dnf-1.1.3-1.fc22.noarch
so I removed the older version:
# rpm -e --nodeps dnf-1.1.1-2.fc22.noarch
This is probably fine, but I would've tried to avoid using --nodeps, and
make the best effort to go through the process without using --nodeps, by
removing all other duplicated packages that have a listed dependency on dnf,
and then finally removing the duplicated dnf package.
The problem is with systemd, which is NOT duplicated:
# rpm -q systemd
# rpm -V systemd
S.5....T. c /etc/sysctl.conf
This is fine. It is normal for these files to be modified, after
# rpm --rebuilddb
and I tried to remove duplicated packages:
# dnf remove $(dnf repoquery --duplicated --latest-limit -1 -q)
Error: The operation would result in removing the following protected
packages: systemd, dnf.
but it insists in removing systemd and dnf again.
How can I proceed next?
The list of packages you get from that dnf repoquery also includes the
This is wrong.
It is normal for multiple kernel packages to be concurrently installed. You
should take that duplicated list, and manually delete all of the kernel
packages from it.
So, that's one thing that's definitely wrong there. You'll need to take the
list produced by dnf repoquery, and manually delete all the kernel packages
from that list.
That still doesn't explain why dnf is trying to remove itself and systemd,
though. It's true that the kernel-core package lists a dependency on
systemd. But the same dependency would also be listed in the newest version
of kernel-core, which would remain installed, and this should be sufficient
to exclude systemd from being uninstalled.
Barring some other, undetected, corruption on your system (unlikely, since
you executed rpm --rebuilddb), I would say that this is a bug in dnf's
dependency resolution. dnf sees that some of the packages that are slated to
be removed have a dependency on dnf and systemd, which are protected, and
aborts; even though it is not going to actually remove either dnf or systemd.
You should be able to work around this likely bug by taking the overall list
of duplicated packages, and manually trying to dnf remove successively
smaller parts of the list; trying to remove as many of the duplicated
packages as possible, using dnf remove. Then, use rpm -e to remove only the
packages that end up triggering this suspected bug.