Package downgrade on CentOS 8.4 > Rocky 8.4 conversion

Dear all,
I just migrated a CentOS 8.4 box to Rocky Linux 8.4 using the script. The process was very smooth!

I am writing here because some packages were marked as downgrades. More specifically:

 dhcp-client                            x86_64  12:4.3.6-44.el8_4.1                     baseos      317 k
 dhcp-common                            noarch  12:4.3.6-44.el8_4.1                     baseos      206 k
 dhcp-libs                              x86_64  12:4.3.6-44.el8_4.1                     baseos      147 k
 httpd                                  x86_64  2.4.37-39.module+el8.4.0+571+fd70afb1   appstream   1.4 M
 httpd-filesystem                       noarch  2.4.37-39.module+el8.4.0+571+fd70afb1   appstream    37 k
 httpd-tools                            x86_64  2.4.37-39.module+el8.4.0+571+fd70afb1   appstream   105 k
 libnghttp2                             x86_64  1.33.0-3.el8_3.1                        baseos       76 k
 libpq                                  x86_64  13.2-1.el8                              appstream   196 k
 mod_http2                              x86_64  1.15.7-3.module+el8.4.0+553+7a69454b    appstream   153 k
 mod_ssl                                x86_64  1:2.4.37-39.module+el8.4.0+571+fd70afb1 appstream   133 k
 python3-distro                         noarch  1.4.0-2.module+el8.3.0+120+426d8baf     appstream    36 k
 python36                               x86_64  3.6.8-2.module+el8.3.0+120+426d8baf     appstream    18 k
 qemu-guest-agent                       x86_64  15:4.2.0-48.module+el8.4.0+534+4680a14e appstream   244 k

Using httpd-filesystem as an example, I saw a “downgrade” from httpd-filesystem-2.4.37-39.module_el8.4.0+778+c970deab.noarch to httpd-filesystem-2.4.37-39.module+el8.4.0+571+fd70afb1.noarch

The last pre-migration httpd-filesystem update was on 2021-06-03T23:07:54Z, so it somewhat surprises me to see a different package version for Rocky. Is that a fluke, or an expected outcome?

Thanks you all for your hard work.

I encountered the same thing using a similar earlier script. The issue in my case, was I needed to perform a yum update on the CentOS 8.4 first to get the packages to the latest version just prior to running the script. I tested this several times. I tested on same virtual machine reverting back to previous snapshot until I determined that a dnf update or yum update resolved things.

The script tested against, which isn’t official and the official script is better.

dnf update

rpm -e --nodeps centos-gpg-keys centos-linux-release centos-linux-repos
rpm -ivh \ \ \
dnf distro-sync -y

Hi, thanks for your feedback.

My machine was up-to-date because it runs, each night, a yum upgrade -y && reboot. So it seems more about some package upgrades not finding their way in the official Rocky repo.

Anyone with similar findings?

Hi all, thanks for using the script! Just a reminder that you can/should report any issues with this script on GitHub here.

Hi, should I use the linked Github issue page even if the problem does not seem related to the script itself, rather to some missing updates in Rocky repo? Just asking…


@shodan , was the machine using Centos 8 or Centos 8 stream? I’ve seen similar reports on Red Hat’s lists.

Especially for “Modules” its just a cosmetic issue. It claims to be a downgrade but its an “upgrade”.
This is due the hashes in the “release” name (+778+c970deab vs. +571+fd70afb1). These hashes are
individual and depended of the git repo and because 571 < 778 its shown as downgrade …

@DavidJohnston it was a CentOS 8.4 machine (not Stream).

@Ritov This make sense, thanks! However, it remain the (small) discrepancy between what provided by CentOS 8.4 and Rocky 8.4.