Seamless Migration: CentOS 8 to Rocky Linux

CentOS 8 reached end-of-life in December 2021. Continued operation on unsupported infrastructure is a direct risk: no security patches, no bug fixes, and an increasing set of broken dependencies as repositories disappear.

Rocky Linux—community-built, ABI-compatible with RHEL—covers this gap. Direct migration preserves service continuity for production workloads in cloud and on-prem.

Before You Begin

Host migrations seldom go as simply as the tool’s README implies. Start with the non-negotiables:

• Full machine backup: Disk snapshot (LVM or VM-level) or file-level backup (e.g., rsync, tar). Snapshots in VMware, AWS, or Proxmox are significantly faster to restore than bare metal.
• Root or sudo access: Standard. Some operations will fail quietly if permissions are insufficient.
• Stable connectivity: The migration script pulls packages from Rocky mirrors; latency or dropouts can corrupt transaction state.
• Inventory validation: Capture kernel, installed packages, custom repo state.

cat /etc/os-release             # Confirm CentOS Linux 8.x
rpm -qa --qf '%{NAME}\n' > pkgs.txt
dnf repolist > current-repos.txt
uname -r                        # Kernel version (warn for vendor modules)

Tip: Document the output of these commands. It’s your rollback insurance if post-migration troubleshooting is needed.

1 — Patch and Reboot

No migration should proceed on a partially patched OS. Unapplied updates mean mismatched RPMs and unpredictable failures.

sudo dnf clean all
sudo dnf update -y
sudo reboot

After reboot, confirm clean state:

cat /etc/centos-release
df -hT            # Disk space (insufficient space is a common gotcha)

2 — Audit and Disable Non-Base Repositories

Third-party repositories (e.g., Remi, ELRepo, custom in-house) create package conflicts during distro migration. EPEL can be disabled now and re-enabled post-upgrade.

Example audit:

ls /etc/yum.repos.d/
sudo dnf repolist all

Disable all except CentOS base and updates:

sudo dnf config-manager --disable <repo_id>

Store the original repo configuration. Some plugins (e.g., DNF versionlock) may interfere—confirm their state.

3 — Fetch and Prepare the migrate2rocky Tool

Rocky’s migration script, migrate2rocky, handles repo switching, package moves, and system metadata updates with minimal manual intervention. Version as of this writing: migrate2rocky.sh (2023-09-21).

curl -O https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky.sh
chmod +x migrate2rocky.sh
sha256sum migrate2rocky.sh    # Always verify hash for supply-chain trust

4 — Perform a Dry Run

Never run migration scripts "blind." The -c flag checks the entire process, highlighting breakpoints:

sudo ./migrate2rocky.sh -c

Look for output lines such as:

[WARN] Ephemeral package conflicts: kernel-modules-extra-nvidia
[INFO] To be replaced: centos-stream-release -> rocky-release

Spot any custom/critical packages (nvidia-dkms, custom OpenSSL)? Investigate before proceeding. Hardware-specific drivers often require a different approach.

5 — Switch to Rocky Linux

Confident in dry-run results? Proceed.

sudo ./migrate2rocky.sh -r

Core actions:

• YUM repo files (/etc/yum.repos.d/*) are rewritten for Rocky mirrors.
• All CentOS branding in /etc replaced (e.g., /etc/centos-release → /etc/rocky-release).
• DNF refreshes all RPMs for compatibility.
• System metadata, such as /etc/os-release, gets updated.

Depending on your package count and I/O, expect 10–40 minutes. Network drop? The script is resilient, but don't interrupt unless absolutely necessary.

Known issue: Service restarts (sshd, firewalld) can transiently drop connections. For remote sessions, favor screen/tmux.

6 — First Boot: Post-Migration Hardening

Immediately after migration:

sudo reboot
cat /etc/os-release

Expected:

NAME="Rocky Linux"
VERSION="8.8 (Green Obsidian)"
ID="rocky"

• Reactivate required repositories one at a time
  • Test each with sudo dnf repolist
• Re-add EPEL

  sudo dnf install epel-release -y
  

• Synchronize packages

  sudo dnf distro-sync -y
  

• Validate all major services

  sudo systemctl status httpd
  sudo systemctl status mariadb
  

• Examine system logs:

  journalctl -p 3 -xb    # Show critical errors since boot
  

Note: SELinux contexts may need relabeling, especially with custom /var or /srv mounts.

7 — Regression and Functionality Testing

Functional validation is mandatory. Don’t assume package migration preserves subtle local changes:

• Spin up test jobs (CI/CD runners, batch workers).
• Check logins via all expected methods (local, SSH key/cert, LDAP).
• Query databases, hit endpoint URLs, monitor for application error logs.

A simple curl http://localhost:80/ isn’t a validation for a multi-service web stack. Use integration tests if available.

Automation: Ansible Example

For estates of more than a handful of hosts, use automation tools. This reduces variance and audit time.

- name: Rocky Linux migration
  hosts: centos8fleet
  become: yes
  tasks:
    - name: Download migrate2rocky
      get_url:
        url: https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky.sh
        dest: /usr/local/bin/migrate2rocky.sh
        mode: '0755'
    - name: Run migrate2rocky
      command: /usr/local/bin/migrate2rocky.sh -r
      register: migration
    - name: Record migration logs
      copy:
        content: "{{ migration.stdout }}"
        dest: "/var/log/migrate2rocky-ansible.log"

Note: For clusters, stagger reboots to avoid downtime.

Troubleshooting Reference

Atypical edge case (seen once): If migration script hangs on stale NFS mounts, unmount or remount with soft option before retrying.

Conclusion

Production migrations are won or lost in the preparation phase. Trust but verify: always run dry, maintain current and tested backups, and give special consideration to vendor modules or in-house daemons.

Rocky Linux 8.x is a stable drop-in for CentOS 8 hosts—assuming process discipline is followed. Quick-fix “one-liners” often miss lurking configuration drift. If you encounter failures that persist after the above, consider rebuilding from Rocky install media. Sometimes that's cleaner.

Non-obvious tip: On virtual platforms (e.g., VMware, AWS, GCP), snapshot before disabling repos—sometimes, network changes during migration can leave agents or monitoring tools in a broken state before you realize it.

For advanced deployments (complex multi-homed routing, custom security modules), perform staged cutovers and leave sufficient maintenance windows. Consider alternate distros—AlmaLinux, Oracle Linux—if Rocky's cadence ever lags.

Migration isn’t glamorous, but it’s defendable.