Dnf update fails with hanging during the update

Ask Fedora
,
1

I have a system that repeatedly fails during upgrades using dnf
It has been having with various errors, including failure of gpg check and file conflicts that halt the upgrade.

While trying to fix those errors I decided to do a 100% reinstall since more than 3/4 of the installed packages still showed as originating from the “unknown” repo. (this system was recently upgraded from f40)

The reinstall began hanging with post install scriplets for differing selinux packages. After waiting more than an hour for the scriplets to end I wound up doing a forced reboot from an ssh session, but it still does the same.

Further investigation reveals that apparently the reinstalled packages as well as the original are now showing as duplicates. Distro-sync also does not work, with the same symptoms.
This is a small part of the dnf list --showduplicates --installed output.

zimg.x86_64                                          3.0.5-3.fc41                        <unknown>
zimg.x86_64                                          3.0.5-3.fc41                        <unknown>
zip.x86_64                                           3.0-41.fc41                         <unknown>
zip.x86_64                                           3.0-41.fc41                         <unknown>
zix.x86_64                                           0.4.2-2.fc41                        <unknown>
zix.x86_64                                           0.4.2-2.fc41                        <unknown>
zlib-ng.x86_64                                       2.1.7-3.fc41                        <unknown>
zlib-ng.x86_64                                       2.1.7-3.fc41                        <unknown>
zlib-ng-compat.i686                                  2.1.7-3.fc41                        fedora
zlib-ng-compat.x86_64                                2.1.7-3.fc41                        <unknown>
zlib-ng-compat.x86_64                                2.1.7-3.fc41                        <unknown>
zlib-ng-compat-devel.x86_64                          2.1.7-3.fc41                        <unknown>
zram-generator.x86_64                                1.1.2-12.fc41                       <unknown>
zram-generator-defaults.noarch                       1.1.2-12.fc41                       <unknown>
zstd.x86_64                                          1.5.6-2.fc41                        <unknown>
zstd.x86_64                                          1.5.6-2.fc41                        <unknown>
zvbi.x86_64                                          0.2.42-1.fc41                       <unknown>
zvbi.x86_64                                          0.2.42-1.fc41                       <unknown>
zxcvbn-c.x86_64                                      2.5-3.fc41                          <unknown>
zxcvbn-c.x86_64                                      2.5-3.fc41                          <unknown>
zxing-cpp.x86_64                                     2.2.1-2.fc41                        <unknown>
zxing-cpp.x86_64                                     2.2.1-2.fc41                        <unknown>

I see 4120 lines in that output.

How can I clean this up, verify that all packages have been installed by dnf5, and get this server back in operation?

@vgaetera I know you have had many solutions to this type problem. Any advice here?

EDIT
The command dnf repoquery --duplicates returns 1422 results.

2

I don’t know what you expect from that, but --showduplicates can be used to show all version of a package from the various repositories. For example
dnf list --showduplicates kernel
shows

Updating and loading repositories:
Repositories loaded.
Installed packages
kernel.x86_64 6.12.6-200.fc41 updates
kernel.x86_64 6.12.7-200.fc41 updates
kernel.x86_64 6.12.8-200.fc41 updates

Available packages
kernel.x86_64 6.11.4-301.fc41 fedora
kernel.x86_64 6.12.8-200.fc41 updates

To check for duplicates in the installed packages it is dnf check --duplicates.

Does that mean re-install from live media, or something else?

3

  1. Make sure that the storage and RAM are fine and sufficient and the filesystem is consistent, otherwise you may end up in an endless loop of errors.

  2. Switch SELinux to permissive mode or temporarily disable it to avoid related errors.

  3. Perform distro-sync and remove duplicates if any, assuming you are using DNF5:

sudo dnf distro-sync --refresh
sudo dnf reinstall $(dnf rq --duplicates --latest-limit=1 --qf="%{name}\n")

Make sure the database points to the latest release, otherwise explicitly specify the release version until the issue is resolved:

sudo dnf --dump-variables
sudo dnf ... --releasever=41

If necessary, ignore protected packages:

sudo dnf ... --setopt=protected_packages=
sudo sed -i -e 's/^/#/' /etc/dnf/protected.d/*

Any blocking package can be manually removed, ignoring its dependencies:

sudo rpm -e --justdb --nodeps package_name
  1. Check for problems in the RPM database, rebuild it, verify integrity for all installed packages and reinstall corrupted ones if any:
sudo dnf check
sudo rpm --rebuilddb
sudo rpm -V -a
  1. Enable SELinux and fix labels for the entire filesystem.
2 Likes
4

To what you posted I added an additional thing, and that may have solved it completely.

I decided to perform the reinstall in increments.
I used dnf reinstall a\* and it worked through all the packages that began with a except those that for whatever reason showed multiple versions in the output of dnf repoquery --duplicates. Those gave a package already installed message and caused the reinstall to fail.
For those I performed an upgrade with dnf upgrade <package>. Each then showed 1 package being installed and up to 4 (almost all with the same version) to be removed. I assume this was caused by the failed reinstall that installed the new package but failed to complete far enough to remove the older packages.

It was very tedious since I had to do the same thing multiple times as I worked through the entire alphabet only reinstalling smaller lists each time.

When done there were still about 45 packages that failed to upgrade and that was managed with the distro-sync --refresh command. Though even that failed on some until I had completed the cleanup of duplicates. I had to do the upgrade on each package name for some of those.

Thanks @vgaetera for the detailed suggestions.

Note that I had added the --installed option to that so it only showed those that were on the system, not what was available

If you noted from the segment of duplicates I posted, all showed the same package name and an identical fc41 version though there were a few with different versions scattered through the extremely long list

1 Like
5

For me dnf list --showduplicates --installed and dnf list --installed produce the exact same listing.

6

Hmm
I did not try that.

The dnf repoquery --duplicates does not show the same though

A reinstall of everything already installed.

7

If a similar issue occurs again, you can try automating some steps with scripting.
The package list can be split alphabetically to groups or processed one by one:

for PKG in {0..9} {a..z}; do ... ${PKG}\*; done
for PKG in $(rpm -q -a --qf="%{name}\n" | sort -u); do ... ${PKG}; done

In addition, you can force DNF to run non-interactively:

sudo dnf -y ...

Anyways, it’s great that you managed to solve the problem.

2 Likes
8
  • I want to mention that I experienced this too. There may be a bug in the upgrade process that needs fixing.
  • I inferred from deprecation notice for Fedora-37, that mbr legacy bios install perhaps last works on Fedora-38 . Can we know definitely which fedora version no longer can do it?
  • So the plan was to install Fedora-38 using liveiso and then upgrade to Fedora-42
  • After managing some small hiccups, like uninstalling missing packages, disabling modularity repo. I managed to push through the dnf system upgrade. About 22xx packages were downloaded and installed.
  • The upgrade became stuck at the end of package verification
    zxing-cpp.x86_64 ...
    while one can switch tty Using Alt-2/3/4/5 , I could not login as I had not configured a password for root, but only for the first-install-user admin(uid=1000), member of wheel
    So I concluded that system was responsive (not hung/frozen) but not progressing
    I had waited a long time, before I concluded that it isn’t doing anything
  • I did a Ctrl-ALt-Del to do a system reboot which brought back up Fedora-42 gdm login with no issues
  • As described above the package repository field for each package as shown by dnf list --installed had blanked out to unknown
  • I was able to fix the repo unknown using a bash for-loop reinstall of each package in a manner as described above.
  • I think the whole double download of the packages is a waste of time, and maybe bandwidth for the repo servers.
  • There should be a easy way to fix the field, a script that determines the repo the package is present in and directly set the field in the dnf/rpm database, without attempting a download/reinstall.
9

It can install on a pre-existing mbr partition table as long as it has at least one partition defined. If no partition is defined, it will create a GPT partition table. I just tested this with Fedora 41.

1 Like