Migrating from CentOS to Rocky Linux while preserving binary compatibility

Problem: CentOS end‑of‑life leaves workloads without updates

Many production systems still run CentOS 8 or CentOS Stream 8. After the CentOS Project shifted focus, those distributions no longer receive the regular security errata and bug‑fix updates that enterprise workloads expect. Administrators need a drop‑in replacement that offers the same binary packages, the same versioning scheme, and the same ten‑year support lifecycle without recompiling custom applications.

Thesis: Rocky Linux provides 1:1 binary compatibility via source rebuilds

Rocky Linux is built by taking the exact source RPMs (SRPMs) released by Red Hat Enterprise Linux (RHEL) and rebuilding them with the same build tools, macros, and configuration that Red Hat uses. The result is a distribution that is byte‑for‑byte identical to RHEL for every package, ensuring that any binary that runs on RHEL will run unchanged on Rocky Linux. This approach also preserves the AppStream module streams, package naming, and version‑release (NEVRA) numbers.

How Rocky Linux achieves compatibility

• Source acquisition: Rocky Linux pulls the public RHEL SRPMs from git.centos.org as soon as they are released.
• Reproducible build: The SRPMs are compiled in a Koji/MBS instance that mirrors Red Hat’s build environment, including the same compiler versions and macro files.
• Metadata parity: The resulting binary RPMs retain the original NEVRA, and the repository metadata uses the same checksums and filelists as the official RHEL repositories.
• Release tracking: The rocky-release package provides a version file and configures DNF to point at community mirrors that carry the rebuilt packages.

Because the build process is deterministic, administrators can verify compatibility by comparing the NEVRA of any installed package with the corresponding RHEL package.

Worked example: migrating a CentOS 8 system to Rocky Linux 8

The following steps assume you have root access on a CentOS 8 system and that you have a recent backup of critical data.

1. Install the Rocky Linux release package

   Download the latest rocky-release RPM for version 8 from the project’s mirror and install it:

   # dnf install -y https://download.rockylinux.org/pub/rocky/8/BaseOS/x86_64/os/Packages/rocky-release-8.5-1.el8.noarch.rpm
   
   This command replaces the centos-release file and adds repository definitions pointing to Rocky mirrors.

2. Swap the repository files

   Remove the old CentOS repository files and reinstall the Rocky ones to ensure clean metadata:

   # dnf -y remove centos-release* centos-gpg-keys*
   # dnf -y install rocky-repos
   
   After this step, dnf repolist should show repositories with base URLs ending in rockylinux.org.

3. Synchronize packages to the Rocky baseline

   Perform a distribution sync, which will replace CentOS packages with their Rocky equivalents while preserving configuration files in /etc:

   # dnf -y distro-sync
   
   During the sync, DNF will report which packages are being downgraded, upgraded, or reinstalled. No package should be removed unless it is absent from the Rocky repositories.

4. Verify the migration

   Check that the rocky-release package reflects the expected version and that key packages match RHEL NEVRA:

   # rpm -q rocky-release
   # rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' bash coreutils
   
   Compare the output with a known RHEL 8 system; the strings should be identical.

5. Confirm AppStream module streams

   Ensure that the module streams available match those documented for RHEL 8:

   # dnf module list --enabled
   
   Look for streams such as nginx:1.18, postgresql:12, etc., and verify they are present.

Trade‑off: dependency on timely RHEL source availability

Rocky Linux can only release updates after Red Hat publishes the corresponding SRPMs. If Red Hat delays a source release (for example, during a embargo period), Rocky’s errata may lag behind the official RHEL errata by a few hours or days. For most workloads this delay is acceptable, but organizations that require strict synchronization with RHEL’s patch schedule should monitor the lag and consider maintaining a local mirror of the Rocky repositories.

Actionable closing: verify and maintain

• After migration, run dnf check-update regularly and apply updates with dnf update -y.
• Periodically inspect the rocky-release version to ensure you are receiving the intended point release.
• Use dnf repolist -v to confirm that all repository URLs point to Rocky mirrors and that the metadata checksums match those published on download.rockylinux.org.
• If you rely on third‑party repositories, test them in a staging environment because they may not be rebuilt for Rocky and could introduce version mismatches.