A new issue is best started in a separate thread instead of hijacking
someone else's thread, as you did. It keeps threads neat and tidy too.
On Mon, 31 Jul 2023 15:11:06 -0700
richard emberson <emberson.rich(a)gmail.com> wrote:
I had a "dnf update" interrupted.
At what stage was it interrupted? If it was during update it isn't as
problematic as if it is during cleanup, I think, when a package could
be left in a partially finished state.
Running "dnf clean all" and then "dnf update" again results in:
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful
transaction. You can remove cached packages by executing 'dnf clean
packages'. Error: Transaction test error:
file /usr/share/doc/glib2/NEWS from install of
glib2-2.76.4-3.fc38.i686 conflicts with file from package
glib2-2.76.3-1.fc38.x86_64 file
/usr/share/locale/en_GB/LC_MESSAGES/glib20.mo from install of
glib2-2.76.4-3.fc38.i686 conflicts with file from package
glib2-2.76.3-1.fc38.x86_64 file
/usr/share/locale/pt_BR/LC_MESSAGES/glib20.mo from install of
glib2-2.76.4-3.fc38.i686 conflicts with file from package
glib2-2.76.3-1.fc38.x86_64 ....... 160 lines of "... conflicts with
file from package ..."
Running "dnf check" gives:
NetworkManager-1:1.42.6-1.fc38.x86_64 is a duplicate with
NetworkManager-1:1.42.8-1.fc38.x86_64 ...
systemd-253.5-1.fc38.x86_64 is a duplicate with
systemd-253.7-1.fc38.x86_64 ...
systemd-udev-253.5-1.fc38.x86_64 is a duplicate with
systemd-udev-253.7-1.fc38.x86_64 ...
xxhash-libs-0.8.1-4.fc38.x86_64 is a duplicate with
xxhash-libs-0.8.2-1.fc38.x86_64 Error: Check discovered 430 problem(s)
What is the problem (aside from the fact that I interrupted the
update) and How can I recover?
I think it was better not to run dnf clean all. You should have just
run a repeat of dnf update because the system would have been in a sane
state. By running clean all, you wiped all metadata.
I think the errors are because there is some cruft left over from the
update. Try using
dnf distrosync
If that doesn't work, you can try
dnf -x glib2 update
to see if it will fix all the other problems and ignore glib2 for now.
Usually, the problem that glib2 is reporting is a packaging error, but
I suspect it isn't in this case because of the update interrupt. Once
everything else is fixed, you might have to manually remove the glib2
packages in conflict because they are cruft left over from the
interrupted update.