How to Fix AlmaLinux ELevate Upgrade Error: A Complete Step-by-Step Guide

Skip the fluff — if you’re reading this, your ELevate upgrade either failed already, or you’re smart enough to check before you leap. Either way, you’re in the right place: this is how to fix AlmaLinux ELevate upgrade errors for good. I’ve spent way too many nights staring at half-upgraded servers that died mid-flight, and the pattern is almost always the same. So here’s the deal: I’ll give you the fix list, the exact commands, and the gotchas nobody mentions up front.

Quick reality check. ELevate is AlmaLinux’s in-place major upgrade tool — the thing you use to go from AlmaLinux 8 to 9, or to drag a CentOS 7 box into the modern era. Under the hood, it runs the Red Hat leapp framework with official upgrade data. It works. But here’s the part nobody says out loud: it’s a house renovation that happens while you’re still living in the house. One wrong package, one missing answer, and you’re locked out of the bathroom — except the bathroom is your production server.

Let me be real about why these upgrades fail. It’s rarely the tool. It’s almost always the environment. Production servers are dirty. They carry third-party repos like EPEL and Remi that got enabled five years ago and forgotten, custom kernels someone compiled once and never removed, and packages installed by hand from some random URL. leapp checks all of this during the preupgrade phase and writes every single problem into a report. The kicker? Most admins skip the report and jump straight into the upgrade. That’s mistake number one.

Mistake number two is skipping the backup. I know — you have a snapshot somewhere. But “somewhere” isn’t the same as “verified and recoverable.” When an upgrade dies at sixty percent, the RPM database is in a weird state, and a snapshot from last week might not cut it if you’ve changed configs since. Make the snapshot, test the restore, and only then touch leapp. That’s the difference between a thirty-minute fix and a weekend of panic.

And the third thing — the one that trips up even experienced admins — is the answer file. leapp asks a handful of questions during the upgrade, VDO confirmation, authselect checks, that kind of thing. If you don’t answer them in advance, the upgrade stops dead with an inhibitor, and the error message gives you zero hints about how trivial the fix is. I’ll cover that below. Alright, let’s get into the actual steps.

Why AlmaLinux ELevate Upgrade Fails: The Three Real Reasons

Stripped down, every failure I’ve debugged comes down to one of three things: an unread precheck report, a missing answer, or a dirty environment. The environment one is the most common — old repos, blocked packages, and full disks. The good news is all three are fixable before leapp even starts, which is exactly what the steps below do. So instead of treating the symptom, we fix the cause, once, in order.

What a Dying Upgrade Actually Looks Like

For the record, here’s what a failed upgrade looks like in /var/log/leapp/leapp-upgrade.log. Notice the progression: warnings first, then the RPM transaction, then the crash.

2026-08-02 02:11:07.123 INFO Preparing system for upgrade
2026-08-02 02:11:09.487 WARNING One or more repositories are disabled
2026-08-02 02:11:14.002 WARNING Package zram-generator is not supported in target OS
2026-08-02 02:11:22.877 INFO Executing RPM transaction (phase 1/2)
2026-08-02 02:11:28.331 ERROR Transaction check error:
2026-08-02 02:11:28.331 ERROR   file /usr/lib/modules-load.d/zram.conf conflicts between
2026-08-02 02:11:28.332 ERROR   attempted installs of zram-generator and kmod-zbud
2026-08-02 02:11:28.910 ERROR Upgrade cannot continue, please check the report

Lines one through three are the symptom: leapp flags a package it knows won’t survive the transition. The middle lines are the pattern: the RPM transaction starts and immediately hits a file conflict. The last line is the root cause: zram-generator and kmod-zbud are fighting over the same file. Fix the package list first and this whole log never happens.

The Non-Negotiable Prep (Do This First)

Take the snapshot, then verify it. Don’t trust the “snapshot created” message — open the list and confirm it’s there, and if you have a spare box, test the restore. Ten minutes now saves you a very bad weekend.

Step 1 — Update Everything, Then Clean Up

Old boxes carry hundreds of outdated packages, and leapp needs a clean baseline. Bring everything up to date and clear the cache.

cat /etc/redhat-release
uname -r
dnf update -y
dnf clean all

On CentOS 7, swap dnf for yum. And make sure you’re on the latest stock kernel — not a custom one. ELevate loads its own modules during the reboot phase, and a custom kernel is the fastest way to a boot that never finishes.

Step 2 — Tame Your Repositories

List what’s enabled, then disable anything that isn’t core OS repos during the upgrade. You can flip them back on after.

dnf repolist
dnf config-manager --set-disabled epel

EPEL, Remi, and friends hold packages that conflict with the target OS. You don’t need to remove packages yet — just disable the repos. The precheck will tell you exactly which packages have to go. If you spot a repo nobody remembers enabling, disable it too. When in doubt, it goes.

Step 3 — Install ELevate and leapp

Install from the official repo. The commands differ slightly between AlmaLinux 8 and CentOS 7:

# AlmaLinux 8
dnf install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm -E %rhel).noarch.rpm
dnf install -y leapp-upgrade leapp-data-almalinux

# CentOS 7
yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm -E %rhel).noarch.rpm
yum install -y leapp-upgrade leapp-data-almalinux

Confirm both packages landed:

rpm -qa | grep -Ei "leapp|elevate"

Step 4 — Run the Precheck (and Actually Read It)

leapp preupgrade does zero damage. It only inspects the system and writes a report. Run it, grab a coffee, and wait.

leapp preupgrade

Then open the report:

cat /var/log/leapp/leapp-report.txt

Here’s a realistic sample from a production box someone ignored, then paid for:

[INHIBITOR] Some installed RPMs are blocked
Summary: The following RPMs are known to be problematic:
  - kmod-zbud-3.0-1.el8.x86_64
  - zram-generator-0.1.4-3.el8.x86_64
These packages are not supported in the target OS and must be removed.
Remediation: [command]dnf remove kmod-zbud zram-generator[/command]
Risk Factor: high

[INHIBITOR] Required space for the ''' directory is not sufficient
Summary: A required space of about 525 MB is missing on the ''' filesystem.
Remediation: [command]dnf clean all && rm -rf /var/cache/dnf/*[/command]
Risk Factor: high

[CONF] Custom SSH configuration file was detected
Summary: The system is configured with a custom sshd_config.
Remediation: Review and manually apply necessary changes after the upgrade.
Risk Factor: low

Read it top to bottom. [INHIBITOR] means the upgrade will stop unless you fix it. The “Summary” line explains the problem, and “Remediation” literally hands you the command. [CONF] and [WARN] lines are warnings — they won’t stop the upgrade, but read them anyway. Need more detail? /var/log/leapp/leapp-preupgrade.json has the full dump.

Don’t skip this. Nine out of ten “my ELevate failed” tickets I see trace straight back to an unread report.

Step 5 — Clear Every Inhibitor

Remove blocked packages

When the report names packages, confirm they’re the ones actually installed before you remove anything:

rpm -qa | grep -Ei "zbud|zram"

If the output only shows packages you don’t use, remove them:

dnf remove kmod-zbud zram-generator

If you’re not sure what a package does, don’t guess. Check with rpm -qi, ask your team, and only then remove it.

Answer the questions

VDO and a few other checks need explicit confirmation before leapp will proceed:

leapp answer --add --section check_vdo.confirm=True

Or edit /var/log/leapp/answerfile directly and flip the defaults to True. Just make sure it’s answered before you run the upgrade, or it’ll stop cold in the middle of the transaction.

Free up disk space

Check where you stand first:

df -h / /usr /var /boot

Then verify the cache directory before emptying it, and trim the logs:

ls /var/cache/dnf/
dnf clean all
rm -rf /var/cache/dnf/*
journalctl --vacuum-size=200M

Re-check with df -h. Still tight? Resize the partition or move data before you proceed.

Re-run the precheck

Fix everything the report flagged, then run preupgrade once more until it comes back clean:

leapp preupgrade

No new inhibitors? Good. You’re cleared to proceed.

Step 6 — Run the Upgrade

This is the real deal. leapp upgrade stages everything and then asks for a reboot. The actual upgrade finishes during that reboot, and yes — your SSH session will drop. That’s normal.

leapp upgrade

Run it inside tmux or screen so a flaky connection doesn’t kill the log. And don’t — I repeat, don’t — reboot manually while it’s running. Let leapp own the reboot.

Step 7 — Reboot and Verify

Once leapp says it’s ready, reboot:

reboot

When it’s back, verify:

cat /etc/redhat-release
cat /etc/os-release
uname -r

Seeing AlmaLinux 9 with a new kernel? Then re-enable the repos you disabled and do a final sweep:

dnf config-manager --set-enabled epel
dnf update -y

The Errors You’ll Actually See

Here’s the quick-reference table for the errors that show up most often in the wild. Keep it handy — this is what ninety percent of tickets end up being:

Error Message	Likely Cause	Fix
Could not retrieve the upgrade data for 8.9 to 9.4	Elevation repo data unreadable or repo.almalinux.org unreachable	Check internet access and /etc/leapp/files/leapp_upgrade_repositories.repo
Required space for the ”’ directory is not sufficient	Root partition too full	Clear caches and logs, or resize the partition
Some installed RPMs are blocked	Packages not supported on the target OS	Remove the packages listed in the report remediation
Transaction check error	RPM conflicts between old and new packages	Disable third-party repos and remove conflicting packages
Detected VDO feature (needs confirmation)	Required answer not given	Set the answer file with leapp answer
You need to be root	leapp run as a normal user	Switch to root and retry
Unable to load kernel module	Kernel too old or custom	Update to the latest stock kernel first
Server does not come back after reboot	Upgrade failed during the boot phase	Use console access, boot the old kernel, then rollback or restore the snapshot

Pro Tips & Warnings

• Test on a staging clone first. Always. Production is not your lab.
• Pick a wide maintenance window. Preparation alone can take 20-60 minutes, plus the reboot.
• Keep console access (noVNC/KVM) handy from your VPS panel. If SSH dies and the box doesn’t return, that’s your lifeline.
• Write down the current kernel and OS version before you start, so verification is a quick diff.
• Never run leapp upgrade twice on a failed state. Re-read the report, fix it, then re-run.

FAQ

Related Reading

If you’re still preparing the server, or you want to keep an eye on it after the upgrade, these should help:

• Production server backup guide — read this before any upgrade, honestly.
• Monitoring servers with Netdata — watch your box after the upgrade.
• Hardening your SSH server — tighten access while you’re in there.

Done. That’s the whole flow. Before you run anything, do three things: take the snapshot, run the precheck, and read the report. If you still hit a wall, pull /var/log/leapp/leapp-report.txt and match the line against the table above. It’s almost always something in there. Bookmark this for next time, and test the whole thing in staging first — production isn’t your lab.