AlmaLinux ELevate: Turning a 7‑to‑8 Upgrade into a Repeatable Procedure

Why the 7‑to‑8 Upgrade Still Feels Like a Leap

CentOS 7 reached end‑of‑life on 30 June 2024. In a fleet of hundreds or thousands of servers, rebuilding each machine from scratch is slow, risky, and hard to audit. The AlmaLinux project’s ELevate tool was created to make the jump to AlmaLinux 8 (and later to 9) a single‑click, testable process rather than a manual rebuild.

The Core Idea Behind ELevate

ELevate is a community‑maintained wrapper around the upstream LEAPP framework. It bundles migration metadata for RHEL‑like distributions and exposes a simple command line:

sudo leapp preupgrade   # Analyze the system
sudo leapp upgrade      # Apply the new release

Running leapp preupgrade generates /var/log/leapp/leapp-report.txt, which lists every inhibitor that would block a safe upgrade. Fixing those inhibitors and then running leapp upgrade boots the system into a special “upgrade environment”, installs the target release, and returns to normal operation—all within a single reboot.

Step‑by‑Step: CentOS 7.9 → AlmaLinux 8

1. Prepare a sandbox
   
   • Snapshot the VM or create a full disk backup.
   • Ensure the system is fully patched: sudo dnf update -y.
2. Install the ELevate release package
   sudo dnf install -y almalinux-release-8.6-1.el7.elrepo.noarch (replace the version string with the latest release for your source OS).
3. Install the LEAPP upgrade package for your source version
   sudo dnf install -y leapp-upgrade-7.9-1.el7.noarch – the leapp-upgrade package name changes with the source major version.
4. Run the preupgrade check
   sudo leapp preupgrade
   Inspect /var/log/leapp/leapp-report.txt. Typical inhibitors:
   • Multiple installed kernels – only the newest is supported.
   • Third‑party packages not on the AlmaLinux 8 repo.
   • Custom configuration files that conflict with the new release.
5. Resolve inhibitors
   
   • Remove older kernels: sudo dnf remove kernel-<old>.
   • Mark third‑party packages for removal or replace them with AlmaLinux 8 equivalents.
   • Answer any interactive prompts that leapp presents.
   Re‑run leapp preupgrade until the report shows “No inhibitors”.
6. Perform the upgrade
   sudo leapp upgrade
   The system reboots into the upgrade environment, applies the new packages, and returns to the main OS when finished.
7. Post‑upgrade validation
   
   • Check the OS: cat /etc/os-release should report AlmaLinux 8.
   • Verify the kernel: uname -r should match the latest 8.x kernel.
   • Run a quick smoke test of critical services (e.g., systemctl status httpd).

Upgrading from AlmaLinux 8 to 9

The same workflow applies, but you need the 8‑to‑9 packages:

sudo dnf install -y almalinux-release-9.2-1.el8.elrepo.noarch
sudo dnf install -y leapp-upgrade-8.6-1.el8.noarch
sudo leapp preupgrade
# resolve inhibitors
sudo leapp upgrade

Because ELevate uses the LEAPP engine, the upgrade environment is the same regardless of source or target; only the metadata changes.

Trade‑offs & Limitations

• In‑place vs Fresh Install
  
  • In‑place preserves user data, custom configs, and third‑party packages, but also carries any accumulated drift (old packages, manual edits, obsolete drivers).
  • A fresh install starts from a clean, known‑good baseline and is often safer for mission‑critical workloads, but requires re‑application of all customizations.
• Kernel Constraints
  Only the newest installed kernel is supported. Older kernels must be removed before leapp preupgrade will succeed.
• Partition & Filesystem Layout
  Unusual layouts (e.g., root on NFS, very large /boot partitions) may be unsupported; consult the ELevate docs for your environment.
• Third‑Party Packages
  The preupgrade report will flag any packages that cannot be migrated. You must either remove them or find AlmaLinux 9 equivalents.
• Community Support
  ELevate is maintained on a best‑effort basis. Treat the preupgrade report as advisory and keep a tested rollback snapshot.
• Secure Boot
  Historically the upgrade required Secure Boot to be disabled. Verify current hardware requirements before planning the upgrade window.
• Sequential Hops Only
  The tool is designed for single‑step hops (7→8, 8→9). Skipping major versions (e.g., 7→9) is unsupported.

Actionable Checklist for Your Fleet

1. Clone a representative server into a VM and run the full 7→8→9 upgrade path as a dry‑run.
2. Measure the total reboot time and the time to reach a stable state.
3. Keep the snapshot until all post‑upgrade checks pass.
4. Document any custom configuration changes required to resolve inhibitors.
5. Schedule the production upgrades in small batches, treating each hop as a separate preupgrade cycle.

Conclusion

ELevate turns what used to be a daunting, manual rebuild into a repeatable, testable procedure. By running a preupgrade check, fixing inhibitors, and letting the tool handle the heavy lifting, you can keep your fleet on a supported RHEL‑derived release with minimal downtime and predictable results.