Rocky Linux RHEL Compatibility: Migration Pattern and Module Stream Realities

When RHEL compatibility meets a lower-cost path

You have a fleet of RHEL-compatible binaries or scripts that depend on specific library versions, and you're evaluating Rocky Linux as a drop-in replacement without paying full RHEL subscriptions. The engineering promise is straightforward: rebuild from RHEL source RPMs so that binaries, ABIs and package names match RHEL exactly within a major version. But the practical migration isn't just a repository rename. This post walks through the concrete pattern, the module stream realities, and the trade-offs you can actually measure.

The 1:1 binary compatibility promise (within major version)

Rocky Linux is designed as a community rebuild of Red Hat Enterprise Linux, with the explicit engineering goal of 1:1 binary compatibility within a major version. That means a binary compiled against RHEL 9 libraries will run on Rocky Linux 9 without modification, and package names such as bash, glibc, or systemd are identical. The Rocky Build System pulls source RPMs from Koji, reproduces the build in a controlled root, and signs the resulting packages to match RHEL's content and dependency metadata. This is why third-party RHEL-targeted software and vendor binaries often install and run out of the box on Rocky.

Important version boundary: compatibility claims apply within a major release. Rocky Linux 9 maps to RHEL 9. Cross‑major upgrades (e.g., RHEL 8 to Rocky Linux 9) are not supported in place and require a fresh installation or the standard migration path described below.

Migration in practice: swapping repositories and syncing packages

The most common migration pattern relies on swapping the base repositories from RHEL to Rocky and then using dnf to align the package set. Assume you are running a RHEL 9 system and want to transition to Rocky Linux 9. The steps are:

1. Run as root. You need superuser privileges to modify /etc/yum.repos.d/ and install packages system-wide.
2. Back up existing repository files. Move rhel.repo to rhel.repo.bak so you can restore if needed.
3. Add the Rocky Linux 9 base repository. Create a new repo file rocky.repo with the appropriate baseurl for Rocky Linux 9 (e.g., https://dl.rockylinux.org/pub/rocky/9/os/$basearch/).
4. Optionally disable the RHEL subscription repo. If you no longer have a RHEL subscription, disable or remove the rhel-server-7.x style repos to avoid priority conflicts.
5. Run dnf distro-sync. This aligns installed packages to the Rocky Linux versions while preserving configuration files in /etc. Example command:

   dnf distro-sync

   Expected check: after the sync, run cat /etc/os-release and confirm the NAME and VERSION_ID reflect Rocky Linux 9.
6. Verify module streams. If your workload uses AppStream modules (e.g., Python, Node.js), list enabled streams with dnf module list --enabled and compare against RHEL expectations.

Relevant risk: dnf distro-sync may pull in newer versions of packages if Rocky's rebuild lag has produced a slightly different dependency set. Always test this pattern in a container or VM first, and validate that ABI-dependent binaries (e.g., custom kernel modules, compiled language runtimes) still function.

AppStream modularity and module stream behavior

Rocky Linux preserves RHEL's AppStream modularity. dnf module streams allow parallel installation of different versions of the same software family, and module enablement and profiles behave the same as on RHEL. However, module stream defaults can change between minor releases. Enabling a stream pins the system to that stream until explicitly changed, which can create dependency conflicts if mixed with third-party repos.

Practical check: after a repository swap, run

dnf module list --enabled
and confirm the listed streams match what your applications expect. If a stream is unexpectedly disabled, use dnf module enable stream-name to re-enable it, then re-run dnf distro-sync to resolve any resulting dependency shifts.
Trade-offs you can measure
Rebuild lag: Security errata and point releases may arrive on Rocky Linux after they are published for RHEL. The rebuild pipeline is reproducible, but it depends on timely source availability and build infrastructure capacity.
Support timelines: Binary compatibility does not guarantee identical commercial support. CVE backports, SLA terms, and vendor support policies differ between Rocky Linux and RHEL.
Custom kernel or driver builds: If you rely on out-of-tree kernel modules or proprietary drivers, you must validate them against the Rocky Linux kernel ABI. The kernel source is rebuilt from RHEL, but any out-of-tree patches may not carry over.
A practical way to check the result is to compare key package versions and build IDs against RHEL documentation for the same major release. For example, querying rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}' on a known package and cross-referencing with RHEL's errata page can reveal whether the rebuild is in sync.
Actionable next steps
If you're planning a migration, start with a non-production test environment. Swap repositories, run dnf distro-sync, and verify that your critical binaries and module streams behave as expected. Check /etc/os-release, list enabled modules, and run a quick service restart to confirm that ABI-dependent workloads start clean. Only after those checks pass should the pattern be applied to production hosts, and even then, maintain a rollback path using your original RHEL repository backups.