[ELevate] AlmaLinux 9 to 10 Upgrade Failed

C

Can

New member
Joined
Nov 1, 2025
Messages
15
[ELevate] AlmaLinux 9 to 10 Upgrade Failed – Mixed Repositories, RPM DB Rebuild, and Leapp Errors

Hello everyone,

I’ve been trying to upgrade my DirectAdmin server from AlmaLinux 9.6 (Sage Margay) to AlmaLinux 10 using the ELevate / Leapp tool, but the process became very complicated and eventually failed.

Here’s a summary of what happened:
  1. I started the upgrade with the usual leapp preupgrade and leapp upgrade steps.
  2. The first problem appeared with duplicate YUM/DNF repositories and unsupported upgrade warnings.
  3. I manually disabled several Imunify360 rollout repos and created custom .repo files for AlmaLinux 10 BaseOS and AppStream.
  4. DNS resolution failed multiple times during the process (Curl error 6 - couldn’t resolve host repo.almalinux.org), so I had to manually add Google DNS entries to /etc/resolv.conf.
  5. Later, the RPM database got corrupted and I had to rebuild it manually using:

    systemctl stop packagekit
    rm -f /var/lib/rpm/__db*
    rpm --rebuilddb -v

  6. After that, dnf started working again, but the Leapp upgrade stopped several times with messages like:
    • “Upgrade is unsupported”
    • “Unable to install RHEL 10 userspace packages”
    • “A YUM/DNF repository defined multiple times”
    • “Actor rpm_scanner unexpectedly terminated with exit code 1”
  7. Even after running with:


    LEAPP_UNSUPPORTED=1 LEAPP_UNSUPPORTED_INHIBITOR=1 LEAPP_DEVEL_SKIP_RHSM=1 leapp upgrade --reboot

    …the system never actually created the leapp-upgrade initramfs, and the GRUB menu didn’t show any upgrade option.

  8. After several attempts, the system became a hybrid between EL9 and EL10 packages — some updated (rpm, python3, systemd) but others still from EL9.
    Network and repository configurations were partially broken, and dnf metadata conflicted.

At this point, I decided to stop the upgrade and restore from my AlmaLinux 9 snapshot, because it’s no longer safe or stable to continue.
The server technically works, but it’s not a clean upgrade environment anymore.


Has anyone here successfully upgraded DirectAdmin + Imunify360 servers from AlmaLinux 9 → 10?
If yes, what was your exact step-by-step process?
Did you have to manually create AlmaLinux 10 repos, or did ELevate handle that automatically?

Any guidance or working example would be appreciated — I’d rather prepare a clean 9.6 → 10 migration path than risk breaking production again.

Thanks in advance!


– Can
 
JosKlever said:
@Can It sounds like you have modified so much, it has become a mess. This isn't a DirectAdmin issue though, so you should probably be able to find more help on https://forums.almalinux.org
This topic is about the support of AlmaLinux 10 and DirectAdmin, not for upgrading AlmalLinux.
Click to expand...
I had taken a snapshot from Hetzner, so I quickly rolled back to it. I’ll try my luck on the AlmaLinux forum instead. Thanks a lot! I’ll stick with AlmaLinux 9 for now — :)
 
Hetzner spins virtual servers with old network device naming schemes. And if it happens you use a public network as well as a private network on a virtual server, you will have either:

- eth0 and eth1, or
- eth0 and enp7s0 (or anything alike).

In either of the cases leapp preupgrade will fail with the error:

Bash: 
============================================================
                      REPORT OVERVIEW
============================================================

Upgrade has been inhibited due to the following problems:
    1. Unsupported network configuration

saying this:

Risk Factor: high (inhibitor)
Title: Unsupported network configuration
Summary: Detected multiple physical network interfaces where one or more use kernel naming (e.g. eth0). Upgrade process can not continue because stability of names can not be guaranteed.
Related links:
- How to Perform an In-Place Upgrade when Using Kernel-Assigned NIC Names: https://access.redhat.com/solutions/4067471
- RHEL 8 to RHEL 9: inplace upgrade fails at "Network configuration for unsupported device types detected": https://access.redhat.com/solutions/7009239
Remediation: [hint] Rename all ethX network interfaces following the attached KB solution article.
Key: d3050d265759a79ce895e64f45e9c56e49b3a953
Click to expand...

The same true for RHEL 9 and even RHEL 10 (AlmaLinux as well). Hetzner makes it use eth0 on RHEL 9 and RHEL 10 as of yet.

As soon as you detach the private network the leapp preupgrade succeeds.

This is the only limitation from the platform and/or a virtualisation. All other inhibitors related to RPM and REPOSITORIES are a particular case of a specific setup performed by a server administrator. In certain cases one even needs to temporary remove/disable certain RPM/REPOs and re-install them after an OS upgrade.

In some cases Zabbix and EPEL can cause the error:

Bash: 
============================================================
                      REPORT OVERVIEW
============================================================

Following errors occurred and the upgrade cannot continue:
    1. Actor: target_userspace_creator
       Message: Unable to install RHEL 9 userspace packages.

I've got the both:

Bash: 
[root@server ~]# yum repolist
repo id                                                                        repo name
appstream                                                                      AlmaLinux 8 - AppStream
baseos                                                                         AlmaLinux 8 - BaseOS
elevate                                                                        ELevate
epel                                                                           Extra Packages for Enterprise Linux 8 - x86_64
extras                                                                         AlmaLinux 8 - Extras
zabbix                                                                         Zabbix Official Repository - x86_64
zabbix-non-supported                                                           Zabbix Official Repository (non-supported) - x86_64
zabbix-tools                                                                   Zabbix Official Repository (tools) - x86_64
[root@server ~]#

In order to solve the issue I will need temporary remove Zabbix from the server.
 
It's support only base repo from OS provider, extra repo required to temporary disabled.
Because when switch to Rhel10, all of your service not work anymore until re-install/build the service.
 
You must log in or register to reply here.
Back
Top