Use case for dnf distro-sync

Upgrading a Linux distro can go smoothly, or sometimes there can be issues. One issue we encountered in our testing pipeline is what seems to be a DNF/RPM issue with basic packages being unavailable, in this case, in a way that prevents even the most basic dependencies from being fulfilled. For instance, it may look like this (the actual versions may differ of course, as well as what package is the issue): Problem: package golf-513-1.el9.x86_64 from copr:copr.fedorainfracloud.org:golf-lang:golf-lang requires gcc, but none of the providers can be installed - package gcc-11.5.0-5.el9_5.x86_64 from appstream requires glibc-devel >= 2.2.90-12, but none of the providers can be installed - cannot install the best candidate for the job - nothing provides glibc = 2.34-125.el9_5.3 needed by glibc-devel-2.34-125.el9_5.3.x86_64 from appstream - nothing provides glibc = 2.34-125.el9_5.3 needed by glibc-devel-2.34-125.el9_5.3.i686 from appstream (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) In this case, a fresh install of Rocky followed by a dnf update/upgrade somehow messed up the package resolution. While a totally fresh install will likely fix this, the following quick command helped in this case: sudo dnf distro-sync --refresh --allowerasing --skip-broken It managed to bring the installation into sync with the distribution itself, effectively making it bare bones "vanilla" box, ready for testing. This may be useful in cases like this; be aware of the risks when using "distro-sync" because it may not in general do what you need. According to its documentation, " It upgrades, downgrades or keeps packages as needed" in order"to synchronize the installed packages with their latest available version from any enabled repository", so it effectively will make the system's packaging to be in sync with repositories. If you have packages that you intentionally upgraded or downgraded to work with something, then it may mess that up. Thus, buyer beware. However, for our purposes here, to bring the system to a "vanilla" state ready for a testing pipeline job, it worked perfectly.

May 4, 2025 - 18:19

Upgrading a Linux distro can go smoothly, or sometimes there can be issues. One issue we encountered in our testing pipeline is what seems to be a DNF/RPM issue with basic packages being unavailable, in this case, in a way that prevents even the most basic dependencies from being fulfilled.

For instance, it may look like this (the actual versions may differ of course, as well as what package is the issue):

Problem: package golf-513-1.el9.x86_64 from copr:copr.fedorainfracloud.org:golf-lang:golf-lang requires gcc, but none of the providers can be installed

  - package gcc-11.5.0-5.el9_5.x86_64 from appstream requires glibc-devel >= 2.2.90-12, but none of the providers can be installed

  - cannot install the best candidate for the job

  - nothing provides glibc = 2.34-125.el9_5.3 needed by glibc-devel-2.34-125.el9_5.3.x86_64 from appstream

  - nothing provides glibc = 2.34-125.el9_5.3 needed by glibc-devel-2.34-125.el9_5.3.i686 from appstream

(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

In this case, a fresh install of Rocky followed by a dnf update/upgrade somehow messed up the package resolution. While a totally fresh install will likely fix this, the following quick command helped in this case:

sudo dnf distro-sync --refresh  --allowerasing --skip-broken

It managed to bring the installation into sync with the distribution itself, effectively making it bare bones "vanilla" box, ready for testing. This may be useful in cases like this; be aware of the risks when using "distro-sync" because it may not in general do what you need.

According to its documentation, " It upgrades, downgrades or keeps packages as needed" in order"to synchronize the installed packages with their latest available version from any enabled repository", so it effectively will make the system's packaging to be in sync with repositories.

If you have packages that you intentionally upgraded or downgraded to work with something, then it may mess that up. Thus, buyer beware. However, for our purposes here, to bring the system to a "vanilla" state ready for a testing pipeline job, it worked perfectly.