How to Handle the AlmaLinux 10 x86_64_v2 Upgrade Without Breaking Your Server
The ELevate NG development branch finally lets system administrators push AlmaLinux OS 9 straight into AlmaLinux OS 10 using the new x86_64_v2 architecture. This upgrade path swaps out the old bootstrapping method for a fresh rootfs image download, which changes how the whole process runs under the hood. Rolling upgrades on live machines always carry a real risk of missing dependencies or broken services, so testing in a sandbox first remains the only safe approach.
Why the AlmaLinux 10 x86_64_v2 Upgrade Changes Everything
The shift to target userspace bootstrapping with an x86_64_v2 rootfs image means the upgrade tool downloads a clean base environment instead of trying to patch the existing system in place. This approach usually cuts down on leftover configuration drift, but it also pulls in a fresh set of binaries that might not match current custom tweaks. Similar rolling upgrades have failed when administrators skipped checking third party modules against the new architecture requirements. The leapp framework handles most of the heavy lifting, yet it still expects a predictable userspace to work with properly.
Getting Ready Before Running Any Commands
Backing up the system is not optional when dealing with development branch tools. Snapshots or full disk images provide a clean rollback point if the bootstrap process stalls or leaves packages in a half installed state. Testing inside a virtual machine first saves hours of troubleshooting later. The official Wiki provides step by step instructions, but those guides assume administrators already know how to verify package signatures and check for conflicting repositories. Running a dry run with the leapp preupgrade command reveals missing dependencies before any actual changes touch the disk.
Setting Up the ELevate NG Repository and GPG Key
Administrators start by pulling the repository configuration directly from the official testing mirror using
sudo curl -o /etc/yum.repos.d/elevate-ng.repo https://repo.almalinux.org/elevate/testing/elevate-ng-el$(rpm -E %rhel).repo
This step matters because standard AlmaLinux repositories do not host the development branch packages needed for the x86_64_v2 transition, and skipping it leaves the package manager blind to the upgrade toolchain. Next comes importing the cryptographic signature with
sudo rpm --import https://repo.almalinux.org/elevate/RPM-GPG-KEY-ELevate
which prevents yum from throwing verification errors when it tries to fetch migration packages. Without that handshake, the system will refuse to trust anything related to ELevate NG.
Installing Leapp Packages and Target Data
The actual upgrade engine relies on two specific packages that must be installed before any files move around. Running
sudo yum install -y leapp-upgrade leapp-data-almalinux-x86_64_v2
pulls the migration framework along with architecture-specific compatibility data that tells leapp how to map old libraries to new ones. Teams targeting the experimental Kitten variant should swap the standard data package for leapp-data-almalinux-kitten-x86_64_v2 instead, since the exact package names dictate which userspace layout gets prepared during bootstrap. Mixing up those identifiers causes silent failures when leapp tries to resolve dependency trees later in the process.
Downloading the Rootfs Image for Bootstrap
The new x86_64_v2 upgrade path requires a clean target environment that lives outside the running system until the transition finishes. Administrators create a dedicated directory and pull the compressed tarball using
sudo mkdir -p /etc/leapp/files/rootfs && cd /etc/leapp/files/rootfs
followed by
sudo curl -LJO https://github.com/AlmaLinux/container-images/raw/refs/heads/10/default/amd64_v2/almalinux-10-default-amd64_v2.tar.xz
This rootfs archive contains the fresh base libraries and binaries that replace the aging userspace during bootstrap, which is why downloading it manually prevents leapp from trying to reconstruct a broken environment on the fly. Those chasing the Kitten build should grab the corresponding kitten-default-amd64_v2.tar.xz file instead, since swapping archives mid-process leaves the system in an unrecoverable state.
Running Preupgrade Checks and Starting Migration
Before any real changes touch the disk, running
sudo leapp preupgrade
forces the tool to scan the current system against strict compatibility rules. The utility generates a detailed report at /var/log/leapp/leapp-report.txt that flags missing dependencies or conflicting configurations without installing anything yet. Administrators should expect this check to fail on default installations since standard setups rarely meet every requirement for the x86_64_v2 transition, and some environments will also trigger an answerfile prompt asking yes or no questions about specific package replacements. Skipping those responses blocks the entire process, so reviewing /var/log/leapp/answerfile becomes mandatory before moving forward. Once the report clears or gets manually overridden with LiveMode experimental flags, executing
sudo leapp upgrade
begins the actual file replacement sequence. The system requests a reboot afterward, and GRUB automatically adds an ELevate-Upgrade-Initramfs entry that boots into the transitional environment without requiring manual menu navigation.
Verifying Post-Reboot Status and Cleaning Up
After the machine comes back online, verifying the new OS version requires checking /etc/almalinux-release and /etc/os-release to confirm the target architecture actually loaded. Administrators should also scan for leftover el9 packages using
rpm -qa | grep el9
since some dependencies survive the bootstrap phase and need manual removal or updating before they cause quiet service failures later. Reviewing both /var/log/leapp/leapp-report.txt and /var/log/leapp/leapp-upgrade.log reveals any silent failures that occurred during service restarts, which is especially useful when custom systemd units refuse to start after the transition. Once everything stabilizes, deleting the temporary placeholder with
sudo rm -rf /etc/leapp/files/rootfs
frees up disk space and removes files that are no longer needed after the transition completes.
Watching the Upgrade Process
Once the rootfs image downloads, the tool begins swapping out old libraries while keeping running services alive as much as possible. The system pauses briefly while it rebuilds critical paths and updates boot configurations. If a service refuses to restart after the transition, checking journal logs usually points straight to missing shared objects or permission mismatches. Developers recommend reporting any hiccups through the Migration Chat Channel so the leapp data repository gets updated with real world edge cases. Skipping that feedback loop leaves other administrators walking into the same traps.
What Comes After Reboot
A successful upgrade lands on AlmaLinux OS Kitten with a modernized userspace and stricter architecture alignment. Administrators should verify custom scripts, cron jobs, and systemd units right away because path changes or deprecated flags often break automation that relied on older library versions. Running a quick package audit helps catch orphaned dependencies before they cause quiet failures down the line. The ELevate team tracks test results actively, so sharing experience directly in their issue tracker keeps the development branch moving forward.
Keep an eye on those logs and report back when things settle. Happy testing.
