Upgrading AlmaLinux 9 to 10 In-Place: A Controlled Migration, Not a Routine Update

You have a production AlmaLinux 9 server that needs to reach AlmaLinux 10. Rebuilding from a fresh image is the safe default—until you account for the application configuration, local users, firewall rules, and monitoring agents that must be recreated and revalidated. The alternative is an in-place major upgrade using the Leapp framework. It is not a routine dnf update; it is a controlled migration that replaces the kernel, initramfs, and core userspace packages. The engineering decision is not whether Leapp can work, but whether your preparation justifies the risk.

Rebuild versus in-place: what you are actually trading

A rebuild produces a clean system with no legacy package debt. It also produces a long checklist: reinstall agents, reapply hardening baselines, restore data, and re-test integrations. An in-place upgrade preserves the existing filesystem layout, local configuration, and installed application stack, but it carries forward every undocumented change and third-party package.

Leapp uses RPM package manager metadata and pre-upgrade reports to plan the transition. AlmaLinux's binary compatibility with RHEL means the same Leapp tooling and RPM ecosystem apply, but AlmaLinux-specific packages such as almalinux-release are handled by the upgrade process. The practical rule is simple: if the host is close to a standard AlmaLinux 9 profile, in-place is a reasonable candidate. If it is a snowflake with custom kernel modules, out-of-tree drivers, or hand-compiled software, a rebuild is usually faster than debugging inhibitors.

What Leapp changes on disk

Leapp does not simply download new versions of your applications. It performs a transaction that swaps the running kernel for the target major version, regenerates the initramfs (the initial RAM filesystem used during boot), and upgrades core userspace libraries. If that transaction fails midway—often because of a full disk or an unclean RPM database—the system can be left unbootable.

The most common blockers are third-party repositories and non-standard packages. Leapp analyzes the enabled repositories and installed package set; anything it cannot map to the target release generates an inhibitor, a finding that blocks the upgrade until it is resolved or explicitly overridden. Version-sensitive behavior matters here: the set of supported upgrade paths, Leapp data files, and known issues change with each minor release. A playbook that worked for AlmaLinux 8 to 9 may not map cleanly to 9 to 10. Always compare your host against AlmaLinux's published upgrade guidance for the specific version pair.

Worked example: pre-flight on a non-production host

Run every step below on a non-production AlmaLinux 9 machine that resembles your target server. You need root privileges for package operations and the Leapp transaction.

1. Record the baseline

Confirm the current release and available space. A full root filesystem is a known cause of mid-transaction failure.

rpm -q almalinux-release
df -h /

Expected check: the release query returns an AlmaLinux 9 version string, and df shows comfortable free space on the root filesystem. If space is tight, resolve it before continuing.

2. Validate the package database

An inconsistent RPM database will break the upgrade transaction.

sudo dnf check

Expected check: the command completes without errors. Any output indicating broken dependencies or duplicate packages must be fixed first.

3. Reduce the repository surface

Third-party repositories are the most frequent source of inhibitors. Disable anything not required for the base operating system.

sudo dnf config-manager --set-disabled <repo-id>

Repeat for each non-essential repository. Expected check: dnf repolist --enabled shows only the AlmaLinux repositories and any vendor repo explicitly required by your applications.

4. Install Leapp and generate the report

Install the Leapp packages provided for AlmaLinux. Package names and data files are version-sensitive, so confirm the exact package in AlmaLinux's current documentation.

sudo dnf install leapp-upgrade
sudo leapp preupgrade

Expected check: the pre-upgrade run produces a report, typically written to a log directory such as /var/log/leapp/. Read it carefully. Inhibitor findings are not advisory; they must be resolved or explicitly accepted before the transaction will proceed. Custom SELinux policies and out-of-tree kernel modules commonly appear here and often require manual rebuilding for the target kernel.

5. Execute the upgrade in a maintenance window

Only after the report is clean (or inhibitors are consciously accepted) should you run the upgrade.

sudo leapp upgrade

Risk: do not run this over SSH if the network stack may change during the transaction. Use a console, IPMI, or other out-of-band session so you can recover if connectivity drops. A failed transaction can leave the system unbootable, so ensure you have a snapshot or full image taken immediately beforehand.

Trade-offs and hard limitations

• No survival guarantee for extras. Locally compiled packages, third-party kernel modules, and custom SELinux policies are not guaranteed to work after the upgrade and frequently need rebuilding.
• Rollback is not a package operation. Once the Leapp transaction begins, the practical rollback is restoring the pre-upgrade snapshot or image. Plan for that before you start.
• Report severity is real. Treating the pre-upgrade report as merely advisory is a common mistake. Unresolved inhibitors will stop the upgrade or produce an unstable system.
• Documentation drift. Because Leapp data files and known issues change with minor releases, rely on AlmaLinux's per-version upgrade guidance rather than an older blog post or internal wiki.

How to verify the result

After the upgrade completes and the system reboots, confirm that the kernel matches the target major release, that critical services start, and that the package transaction is recorded as complete.

uname -r
sudo systemctl status <service-name>
sudo dnf history

Expected check: uname -r reports an AlmaLinux 10 kernel, each critical service is active, and dnf history shows the upgrade transaction as completed. If any service failed to start, investigate before returning the host to production.

The decision to upgrade in place is ultimately about risk concentration. Leapp removes the mechanical work of moving between major versions, but it concentrates risk into a single maintenance window. If you can snapshot, test on a clone, and read the pre-upgrade report as a gate rather than a suggestion, the in-place path can save days of reconfiguration. If you cannot, the rebuild remains the honest choice.