Upgrade AlmaLinux 9 to 10 with ELevate

Start with the CPU, because it picks the tool

An in-place upgrade from AlmaLinux 9 to AlmaLinux 10 with ELevate is four commands and one reboot, but the first thing to do is ask the CPU a question. AlmaLinux 10 ships as two builds for 64-bit Intel and AMD: the default build, compiled for the x86-64-v3 instruction level, and a second build compiled for x86-64-v2 for older processors. A v3 CPU takes the standard ELevate flow. A v2 CPU needs the v2 build, which only ELevate NG (next generation) can install. On a VPS the answer is decided by the CPU model the hypervisor presents to your guest, not by the physical chip in the rack, so you have to look rather than assume.

The x86-64 levels are named sets of instructions. v2 adds SSE4.2 and POPCNT among other extensions, which every mainstream CPU since about 2009 has. v3 adds AVX and AVX2, plus BMI1, BMI2, FMA, F16C, LZCNT, MOVBE and XSAVE, which arrived around 2013. A binary compiled for v3 uses those instructions freely, so on a CPU without them it dies with Illegal instruction the first time it reaches one. That is why the level matters, and why a wrong guess is not recoverable after the reboot.

Ask the dynamic loader

glibc 2.34, which AlmaLinux 9 ships, knows the levels by name and prints the ones the running CPU can execute. Run it as an ordinary user:

/lib64/ld-linux-x86-64.so.2 --help | grep supported

A CPU that can run the default build prints two lines:

  x86-64-v3 (supported, searched)
  x86-64-v2 (supported, searched)

A CPU that cannot prints only the x86-64-v2 line. That is the whole decision: two lines means the standard flow, one line means the v2 build through ELevate NG. If not even the v2 line appears, no AlmaLinux 10 build runs on that CPU, and the box stays on 9 until it moves to different hardware.

Cross-check the flags

The loader answer comes from the same CPU flags that lscpu prints, so you can count them yourself:

lscpu | grep -o -w -E 'avx2|bmi1|bmi2|f16c|fma|abm|movbe|xsave' | sort -u | wc -l

Those eight names are the exact list the leapp checkmicroarchitecture actor tests before it lets an upgrade to a v3 target proceed (the list is X86_64_V3_FLAGS in the actor source as of September 2026). abm is the kernel's flag name for the LZCNT instruction. A count of 8 means v3. Any smaller number means the v2 build, and the missing names tell you which instructions the hypervisor is hiding.

Why would a modern host hide AVX2? Because a cloud that live-migrates guests between machines has to present a CPU model every machine in the pool can honour, and the safe choice is the oldest one. leapp's own remediation hint for this failure says it directly: "virtualization platforms often allow configuring a minimum denominator CPU model for compatibility when migrating between different CPU models." On your own hypervisor you could raise that model. On rented hardware you cannot, so the CPU you were given is the CPU you upgrade on.

Which AlmaLinux 10 build, and which ELevate

The AlmaLinux 10.0 release notes state the policy: "In AlmaLinux OS 10, we will follow Red Hat's decision to ship x86-64-v3 optimized binaries by default, but we will also provide additional x86-64-v2 architecture ONLY for older hardware." The same page sets the expectation for the v2 build: "All 3rd party packages for RHEL10 will target x86-64-v3, while the x86-64-v2 release of AlmaLinux OS 10 will only be suitable for workloads where using the default OS package set is enough, or where users will be able to rebuild any additional packages they require for x86-64-v2 architecture themselves." So a v2 box lands on a build where EPEL (Extra Packages for Enterprise Linux) and vendor repositories may have nothing for it. If your server depends on packages from EPEL or CRB, check that before you upgrade, because a v2 build with no EPEL is a different server than the one you have now.

The ELevate quickstart guide says which tool covers which build: "Currently, upgrades to AlmaLinux 10 and AlmaLinux Kitten 10 on the x86_64_v2 architecture are supported only by the ELevate NG version." ELevate NG is the next-generation branch of the same project. Its repository lives under the testing directory of repo.almalinux.org/elevate, its wiki page is titled a testing guide, and it carries newer leapp builds than the stable repository. That is the honest status as of September 2026: the v2 path works and is documented, and it is the newer, less-travelled code.

The mechanism behind that sentence is one actor. The stable leapp-upgrade-el9toel10 package includes the upstream checkmicroarchitecture check, which inhibits the upgrade on a v2 CPU with a report titled Current x86-64 microarchitecture is unsupported in the target OS, followed by a line naming the missing flags. It does that because the only AlmaLinux 10 the stable tool knows how to build a target from is the v3 one. The NG build of the same package carries a change merged in April 2026 that keeps the requirement at v2 when the target distribution is AlmaLinux, and you hand it a v2 root filesystem to build the target from. Both halves are needed: the relaxed check, and the v2 rootfs.

Update, reboot, snapshot

The quickstart is firm on the starting state: "A fully updated system is required to accomplish the upgrade. Install the latest updates and reboot your machine". The upgrade data is written against the latest 9.x, so a system behind on updates trips the preupgrade checks before anything useful runs.

sudo dnf update -y
sudo reboot

After the reboot, confirm you are on the kernel you just installed with uname -r, and let needs-restarting tell you nothing is still running old code. Then take a provider snapshot. Take it now if you want, but take one again immediately before leapp upgrade, because that command is the point of no return and the rollback section below explains why. The wiki puts it in capitals: "we HIGHLY recommend that you follow system administration best practices and make sure you have backups and/or snapshots of your system before you proceed." A snapshot is the right tool here rather than a backup, and the difference between a snapshot and a backup is the difference between a ten-minute rollback and a rebuild.

Two more things before the tool goes on. Have your provider's console (VNC, virtual network computing, or a serial console) open in a browser tab, because SSH is unavailable during the upgrade reboot and the console is the only place you will see progress. And check free space on / with df -h /. leapp builds a complete AlmaLinux 10 userspace under /var/lib/leapp during preupgrade and downloads every replacement package during upgrade, so a small root filesystem fills up and the report tells you so.

Upgrade AlmaLinux 9 to 10 with standard ELevate (v3 CPU)

Where each package comes from matters, because none of them is in the AlmaLinux base repositories. elevate-release is an RPM you download directly from repo.almalinux.org/elevate; installing it adds the ELevate repository and its GPG (GNU Privacy Guard) key to the box. leapp-upgrade and leapp-data-almalinux then come from that new repository. leapp-upgrade is a virtual name: on a 9 system it resolves to leapp-upgrade-el9toel10, because rpm --eval %rhel prints 9 and the release package points at the el9 repository. The commands are the wiki's, as of September 2026, with dnf where the wiki writes yum (on AlmaLinux 9, yum is a link to dnf):

sudo dnf install -y https://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm
sudo dnf install -y leapp-upgrade leapp-data-almalinux

leapp-data-almalinux holds the repository maps and package-name changes for the AlmaLinux target. Its sibling leapp-data-almalinux-kitten targets AlmaLinux Kitten 10, the rolling development branch, and the wiki spells that out: "leapp-data-almalinux-kitten package is designed for upgrades from AlmaLinux OS 9 to AlmaLinux Kitten OS 10." A server wants the plain one.

Run preupgrade and read the report

sudo leapp preupgrade

This changes nothing on the system except its own working directory. It fetches AlmaLinux 10 repository metadata, builds the target userspace under /var/lib/leapp, runs every check, and writes the report to /var/log/leapp/leapp-report.txt. Read the whole file once, then filter for what blocks you:

sudo grep -B1 -A3 -i inhibitor /var/log/leapp/leapp-report.txt

Each finding carries a risk factor, and the ones marked (inhibitor) stop leapp upgrade from running until you fix them. The inhibitors a VPS usually hits are the microarchitecture check above and a package from a third-party repository with no 10 equivalent. Fix each one and run preupgrade again until the inhibitor grep prints nothing.

Some findings are questions rather than errors. The wiki: "In certain configurations, Leapp generates /var/log/leapp/answerfile with true/false questions. Leapp utility requires answers to all these questions in order to proceed with the upgrade." Read the file, then answer each section with the command the wiki gives:

sudo cat /var/log/leapp/answerfile
sudo leapp answer --section remove_pam_pkcs11_module_check.confirm=True

The section name in your answerfile may differ from that example. Use the one printed in the file.

Upgrade and reboot

Take the snapshot now. Then:

sudo leapp upgrade
sudo reboot

leapp upgrade downloads every package for the new system and prepares a special initramfs. It does not replace anything yet. The wiki describes the reboot: "A new entry in GRUB called ELevate-Upgrade-Initramfs will appear. The system will be automatically booted into it. See how the update process goes in the console." Watch it from the provider console. Inside that initramfs the RPM transaction runs against your real root filesystem, the new kernel is installed, and the machine reboots a second time on its own. SSH answers again only after that second boot.

The ELevate NG flow on a v2 CPU

NG has no elevate-release package. The repository file itself is the release, and you fetch it and the signing key by hand. The data package is the v2 variant, which exists only in the NG repository, and there is one extra download: a root filesystem tarball that leapp uses to bootstrap the target userspace. It has to be a v2 image, because that userspace runs on your CPU during the upgrade, and a v3 image would crash the same way a v3 system would. The commands are the NG testing guide's, as of September 2026:

sudo curl -o /etc/yum.repos.d/elevate-ng.repo https://repo.almalinux.org/elevate/testing/elevate-ng-el$(rpm -E %rhel).repo
sudo rpm --import https://repo.almalinux.org/elevate/RPM-GPG-KEY-ELevate
sudo dnf install -y leapp-upgrade leapp-data-almalinux-x86_64_v2
sudo mkdir -p /etc/leapp/files/rootfs && cd /etc/leapp/files/rootfs
sudo curl -LJO https://github.com/AlmaLinux/container-images/raw/refs/heads/10/default/amd64_v2/almalinux-10-default-amd64_v2.tar.xz

Do not install elevate-release as well. The two repositories carry different builds of leapp-upgrade-el9toel10, and the stable one still enforces v3. If you already installed it on this box, remove it and the leapp packages with sudo dnf remove 'leapp*' elevate-release before adding the NG repository, so the NG build is the one that gets installed.

From here the flow is the same three commands, and the same report file:

sudo leapp preupgrade
sudo leapp upgrade
sudo reboot

With the NG build, a v2 CPU no longer trips the microarchitecture inhibitor for an AlmaLinux target. If your report still shows Current x86-64 microarchitecture is unsupported in the target OS, the installed leapp-upgrade-el9toel10 is the stable build. dnf list installed leapp-upgrade-el9toel10 prints the repository it came from in the last column, and it must read @elevate-ng, the id inside the repo file you downloaded.

After the second reboot

Log in and check what you are running. The commands are the wiki's verification list, with the release file AlmaLinux uses:

cat /etc/almalinux-release
cat /etc/os-release
rpm -qa | grep el9
sudo cat /var/log/leapp/leapp-report.txt
sudo cat /var/log/leapp/leapp-upgrade.log

/etc/almalinux-release should name AlmaLinux 10. The el9 grep lists every package still built for the old release, and the wiki's instruction is to "consider removing them or upgrade them manually." The list always contains the ELevate tooling itself, because every ELevate package, from elevate-release to leapp-data-almalinux, is an el9 build. They have done their job:

sudo dnf remove 'leapp*' elevate-release
sudo rm -f /etc/yum.repos.d/elevate-ng.repo
sudo rm -rf /etc/leapp/files/rootfs

On the NG path dnf prints a no-match line for elevate-release and removes the rest; the second and third lines are the NG cleanup, and the last one is the step the NG guide ends with. Anything else left on the el9 list is a package leapp could not map to a 10 equivalent, most often something from a third-party repository. On a v3 system, find the repository's 10 build and reinstall. On the v2 build, remember the release notes: third-party packages target v3, so that package either gets rebuilt by you for v2 or stays at its 9 version until it breaks.

Two last checks. Run sudo dnf update -y once more, since the repositories the upgrade used may have moved on since leapp cached them. And read the SELinux (Security-Enhanced Linux) state with getenforce, then compare it with what /etc/selinux/config says, so the box is back in the mode you expect.

Rollback: what it means after leapp has rebooted

leapp has no rollback command. Everything up to leapp upgrade is harmless: preupgrade writes only under /var/lib/leapp and /var/log/leapp, and removing the leapp packages puts the box back where it was. Once the machine boots the ELevate-Upgrade-Initramfs entry, the RPM transaction replaces the package set on the real root filesystem and installs the 10 kernel. There is no old system to boot back into. Even if an old kernel entry survives in GRUB, booting it gives you a 9 kernel over a 10 userspace, a different broken machine rather than the old one.

dnf history undo does not rescue this either. It is built for one ordinary transaction whose previous package versions are still reachable in a configured repository, and undoing a normal update with dnf history works well within those limits. The leapp transaction replaces the whole distribution, the dnf that would have to undo it is now the 10 build, and the 9 repositories are no longer configured. Treat it as unavailable.

That leaves the snapshot. Restoring it puts the disk back to the moment before leapp upgrade, every block of it, which is why the snapshot has to be taken right before that command and not the day before. It also means data written between the snapshot and the restore is gone, so for a box holding a database, stop the service or accept the loss before you start. On a VPS this is the entire rollback plan, and it is a good one, because the restore takes minutes and needs no knowledge of what went wrong.

Why Rocky Linux answers this differently

Rocky Linux does not offer an in-place major-version upgrade. Its wiki states the policy: "Upgrades are not generally supported by Release Engineering nor most of the Rocky community." It goes on to mention ELevate as something that "may be able to help you", and then draws the line: "it is not formally tested by the Rocky Linux project and we cannot provide official assistance". In practice the tool cannot help yet either. As of September 2026, neither the stable EL9 ELevate repository nor the NG repository carries a leapp-data-rocky package, and the NG testing guide lists no Rocky 10 target at all. A Rocky 9 server becomes a Rocky 10 server by installing 10 on a fresh VPS and restoring the configuration and data onto it.

That is the second reason the choice between the two distributions matters, alongside the build-from-source policy that most comparisons cover. If in-place upgrades between major releases are part of how you plan to run a server for a decade, the choice between Rocky Linux and AlmaLinux is partly a choice between reinstall-and-restore and ELevate. If they are not, and you rebuild servers from configuration management anyway, the difference disappears. The other end of the spectrum is Fedora, where a supported in-place upgrade lands every six months and the price is a release that is only maintained for about thirteen.

FAQ

How do I know if my VPS CPU supports x86-64-v3?

Run /lib64/ld-linux-x86-64.so.2 --help | grep supported. If the output includes a line reading x86-64-v3 (supported, searched), the CPU runs the default AlmaLinux 10 build and the standard ELevate flow applies. If only the x86-64-v2 line prints, you need the v2 build through ELevate NG. You can confirm with lscpu: the eight flags leapp checks are avx2, bmi1, bmi2, f16c, fma, abm, movbe and xsave, and all eight must be present for v3.

Why does leapp preupgrade say my microarchitecture is unsupported?

The report line Current x86-64 microarchitecture is unsupported in the target OS comes from the checkmicroarchitecture actor, and it means your CPU is missing at least one x86-64-v3 flag while the target leapp knows is the v3 build. On a VPS the missing flags are usually hidden by the hypervisor's CPU model, which you cannot change. Switch to the ELevate NG repository, install leapp-data-almalinux-x86_64_v2 and the v2 rootfs, and run preupgrade again with the NG build of leapp-upgrade-el9toel10.

Can I roll back an ELevate upgrade after the reboot?

Not with leapp, and not with dnf history undo. After the ELevate-Upgrade-Initramfs boot, the root filesystem holds AlmaLinux 10 packages and a 10 kernel, and no 9 system remains to boot into. The only rollback is restoring the provider snapshot you took immediately before running leapp upgrade, which returns the whole disk to that moment and discards anything written since.

Does ELevate upgrade Rocky Linux 9 to Rocky Linux 10?

No. The Rocky Linux wiki says upgrades between major versions "are not generally supported by Release Engineering", and as of September 2026 the ELevate repositories for EL9 carry no leapp-data-rocky package, so there is no Rocky 10 target to select. The supported path on Rocky is a fresh install of 10 followed by restoring your configuration and data.

Where do elevate-release and leapp-upgrade come from?

Not from the AlmaLinux base repositories. elevate-release is downloaded as a single RPM from repo.almalinux.org/elevate, and installing it adds the ELevate repository and signing key. leapp-upgrade, which resolves to leapp-upgrade-el9toel10 on a 9 system, and leapp-data-almalinux are then installed from that repository. For ELevate NG there is no release package: you download the elevate-ng-el9.repo file into /etc/yum.repos.d/ and import the same GPG key by hand, and the v2 data package exists only there.