Unable to upgrade from AlmaLinux 9 to 10 using ELevate

Support
1

I’m trying to upgrade a server from AlmaLinux 9 to 10 following this guide: ELevating CentOS 7 to AlmaLinux 10 | AlmaLinux Wiki . In /var/log/leapp/leapp-report.txt, I see a lot of concerning stuff:

1: Title: Berkeley DB (libdb) has been detected on your system.
I don’t need Berkeley DB anymore (this server runs something which used to use it, but doesn’t anymore). I should be able to remove it, but apparently sudo depends on libdb, so I can’t.

2: Apparently, leapp is unable to identify the AlmaLinux default repositories, and I’m told that software from these may not be upgraded:
Risk Factor: low
Title: Some enabled RPM repositories are unknown to Leapp
Summary: The following repositories with Red Hat-signed packages are unknown to Leapp:
- appstream
- elevate
- baseos
- epel

The list of packages contained in those is practically the entire system! What do I need to do here?

2

After fixing a different error (incorrect mount order in fstab), I’m additionally getting this:

2026-01-12 18:10:57.341151 [ERROR] Actor: target_userspace_creator
Message: Unable to install RHEL 10 userspace packages.
Summary:
    Details: Command ['systemd-nspawn', '--register=no', '--quiet', '--keep-unit', '--capability=all', '--pipe', '-D', '/var/lib/leapp/scratch/mounts/root_/system_overlay', '--setenv=LEAPP_HOSTNAME=Alma-87-amd64-base', '--setenv=LEAPP_EXPERIMENTAL=0', '--setenv=LEAPP_UNSUPPORTED=0', '--setenv=LEAPP_NO_RHSM=1', '--setenv=LEAPP_NO_RHSM_FACTS=1', '--setenv=LEAPP_TARGET_PRODUCT_CHANNEL=ga', '--setenv=LEAPP_UPGRADE_PATH_TARGET_RELEASE=10.1', '--setenv=LEAPP_UPGRADE_PATH_FLAVOUR=default', '--setenv=LEAPP_IPU_IN_PROGRESS=9to10', '--setenv=LEAPP_EXECUTION_ID=1845a607-b1f1-4831-a9ef-15fb9ade2c57', '--setenv=LEAPP_COMMON_TOOLS=:/etc/leapp/repos.d/system_upgrade/common/tools:/etc/leapp/repos.d/system_upgrade/el9toel10/tools', '--setenv=LEAPP_COMMON_FILES=:/etc/leapp/repos.d/system_upgrade/common/files:/etc/leapp/repos.d/system_upgrade/el9toel10/files', 'dnf', 'install', '-y', '--setopt=module_platform_id=platform:el10', '--setopt=keepcache=1', '--releasever', '10.1', '--installroot', '/el10target', '--disablerepo', '*', '--enablerepo', 'almalinux10-baseos', '--enablerepo', 'almalinux10-highavailability', '--enablerepo', 'almalinux10-sap', '--enablerepo', 'almalinux10-saphana', '--enablerepo', 'almalinux10-nfv', '--enablerepo', 'almalinux10-crb', '--enablerepo', 'el10-epel', '--enablerepo', 'almalinux10-appstream', '--enablerepo', 'almalinux10-extras', '--enablerepo', 'almalinux10-rt', 'dnf', 'dnf-command(config-manager)', 'util-linux', '--disableplugin', 'subscription-manager'] failed with exit code 1.
    Stderr: Host and machine ids are equal (ac936b08f9e947ca97156b49e65f67c7): refusing to link journals
            Errors during downloading metadata for repository 'el10-epel':
              - Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=epel-10&arch=x86_64&infra=$infra&content=$contentdir [Could not resolve host: mirrors.fedoraproject.org]
              - Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=epel-10&arch=x86_64&infra=$infra&content=$contentdir&countme=1 [Could not resolve host: mirrors.fedoraproject.org]
            Error: Failed to download metadata for repo 'el10-epel': Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=epel-10&arch=x86_64&infra=$infra&content=$contentdir [Could not resolve host: mirrors.fedoraproject.org]
3

The second error is fixed. My machine had systemd-resolved listening at 127.0.0.53:53, while the container was configured to make DNS queries to 127.0.0.1:53. Adding 127.0.0.1 as an alternate listening address for systemd-resolved made this work.

2 Likes
4

I finally got it working!

I must say, this was a pretty confusing experience. Those two medium and low risk warnings, while they say medium and low risk, don’t really feel that way- it was nerve-wracking. However, the process did work, for which I’m grateful!

1 Like
5

I’m glad you have made it work but you forgot to share how did you solve the issue with libdb.

6

I ended up ignoring it. That error was a red herring- the version of sudo installed on the system at the time depended on libdb, but the version that the upgrade process installed did not. I wish the docs (or the error) had made it clear that you only needed to worry about libdb if your workload needed it, and that essential system packages like sudo would be handled by the system… but I was able to proceed with no issue.

1 Like