Migrate Centos 7 To Almalinux

Migrate Centos 7 To Almalinux

Reading time1 min
#Linux#Migration#OpenSource#CentOS#AlmaLinux#SystemAdministration

Step-by-Step Migration from CentOS 7 to AlmaLinux—with Data Integrity and Minimal Downtime

CentOS 7 reached end-of-life on June 30, 2024. What does this mean for production infrastructure still running on that platform? The attack surface is now wide open, future kernel patches are gone, and vendor support is off the table. There’s no substitute for a supported, actively maintained OS in any compliance-focused environment.

AlmaLinux, an open-source, RHEL-compatible distribution backed by a dedicated foundation, provides a realistic path forward. The migration isn’t just about changing branding; it’s about preserving system functionality, uptime, and auditability. Below is a real-world, field-tested process for migrating CentOS 7 nodes to AlmaLinux 8.x, with strong emphasis on data safety and validation.


Key Drivers for Migration

  • End of Support: CentOS 7 receives no more CVE patches or bugfixes.
  • Compatibility: AlmaLinux 8 is binary-compatible with RHEL 8. Most workloads port seamlessly.
  • Long-Term Stability: AlmaLinux offers multi-year support lifecycles and security updates.
  • Downtime Pressure: Service interruption budgets are shrinking; a clean cutover is necessary.

Prerequisites & Initial Assessment

  • Access: root or passwordless sudo.
  • System Snapshot: If running on virtualization (KVM, VMware, Hyper-V, EC2, etc.), create a VM-level snapshot before making changes.
  • Validate Backups: Don’t just have them—test your restore process.
  • Determine Baseline State:
    • OS minor version: cat /etc/centos-release
    • Storage: Check for LVM or software RAID configurations.
    • Third-party modules: Kernel drivers, DKMS, custom repo packages.

1. Pre-Migration: System Updates and Full Backup

Patch everything first. Out-of-date systems cause unpredictable failures mid-migration.

yum clean all
yum update -y
reboot

Note: If “kernel panic” occurs on reboot, roll back via snapshot immediately.

Take a filesystem-level backup. Consider both rsync and an image snapshot:

rsync -aAXv /etc /var /home /root /srv /opt /usr/local /mnt/backup/
tar czvf /mnt/backup/centos7_full_backup_$(date +%F).tar.gz --exclude={"/proc","/sys","/dev","/run"} /

Hint: Back up /boot explicitly if you use custom kernels or bootloaders.


2. Prune CentOS-Specific Packages and Obsolete Repos

Remove distribution markers and old EPEL keys. Any “zombie” repos can corrupt the RPM database.

yum remove -y centos-release centos-linux-release epel-release
yum clean all && rm -rf /var/cache/yum

Check /etc/yum.repos.d/ for any custom files (especially .repo.rpmnew artifacts). Archive or delete them.


3. Deploy AlmaLinux Migration Tool

Fetch the official almalinux-deploy script:

curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/main/almalinux-deploy.sh
chmod +x almalinux-deploy.sh

Validate signature if you’re in a regulated environment. The script is open-source, but always review before execution.

Run the migration (as root):

./almalinux-deploy.sh

What happens under the hood?

  • All CentOS repos replaced with AlmaLinux.
  • OS branding, release packages, and GPG keys swapped.
  • Incompatible/CentOS-specific packages flagged for removal.
    During execution, you may see RPM transaction conflicts such as:
file /usr/share/redhat-logos conflicts between attempted installs of centos-logos and almalinux-logos

These indicate branding transitions—actual application packages are rarely impacted.


4. Validation: Confirm the Cutover

After migration completes, check:

cat /etc/redhat-release
# Expected: AlmaLinux release 8.x (Electric Cheetah)
rpm -q almalinux-release
dnf repolist

Spot-check your most critical binaries:

rpm -qf /usr/bin/sshd
rpm -qf /usr/lib/systemd/system/mysql.service

Look for orphaned or unresolvable packages:

rpm -Va --nofiles --nodigest | grep missing

Gotcha: Out-of-tree kernel modules like ZFS or proprietary drivers may require manual rebuilds under AlmaLinux 8 kernels.

Check system services:

systemctl --failed
journalctl -p err -b

Troubleshoot any unit failures before rebooting. This is where integration tests should run.


5. First Reboot on AlmaLinux

reboot

If the system fails to boot and you have console access, common failure messages:

dracut-initqueue[...]: Warning: Could not boot.

Often mean missing initramfs modules. In this case, reboot with rescue ISO and rebuild the initramfs.


6. Post-Migration Steps: Updating, Testing, Housekeeping

AlmaLinux 8 uses dnf (not yum). First, clean again:

dnf clean all
dnf distro-sync -y
dnf update -y

Take time to validate:

  • Run all custom and business-critical workloads.
  • Confirm syslog and auditing (e.g., check /var/log/secure and SELinux status).
  • If SELinux is enforcing, run restorecon -Rv / and check for denials: sealert -a /var/log/audit/audit.log
  • Investigate Python and Perl interpreter paths if you have old scripts (/usr/bin/python is not always symlinked in EL8).

Recovery & Rollback

Best-case: Recover via VM/cloud hypervisor snapshot.
Fallback: Restore from full disk or filesystem backup.
Warning: “Undo” scripts or rollbacks from within the altered system are unreliable at best. If in doubt, reimage and restore.


Practical Tips & Known Issues

  • Schedule migrations for off-peak traffic windows—even with fast storage, package transitions may incur unexpected I/O spikes.
  • NFSv3 mounts may require options changes post-kernel upgrade.
  • If you maintain many similar servers, Ansible with idempotent tasks reduces human error.
  • Some monitoring agents hardcode CentOS string checks; test monitoring and alerting stack post-migration.
TaskManual StepsAutomatable via Ansible
BackupXX
System UpdateXX
Migration ScriptXX (with extra QA)
ValidationXPartial

Takeaway

With a structured process, the transition from CentOS 7 to AlmaLinux 8 is straightforward for most non-legacy workloads. The official AlmaLinux deployment tooling handles the majority of RPM and repo migration safely. Problems? They’re nearly always related to local customizations, old drivers, or nonstandard repositories.

Test in a staging environment that mirrors production hardware and applications. The few hours spent validating there eliminates weeks of post-migration firefighting.


Any anomalies or edge cases not covered here? Open an issue upstream or document your workaround for others—migrations are easier when shared.