Upgrade Enterprise Linux 9 to 10#

This document will help you upgrade your EL 9 system to EL 10. More specifically: the instructions will show you how to upgrade AlmaLinux 9 to 10. This instructions MAY also work on Red Hat Enterprise Linux 9 and RockyLinux 9, but haven’t been tested. If you do, and it works, or it requires some changes to this document, please let us know!

Preparation#

Repository#

We updated the way repositories are configured on EL slightly on 2025-06-23. If you installed your Enterprise Linux 9 server, after this, you are good, otherwise you need to update the configuration. Follow the instructions here. It involves installing the repository key and updating the repository config. Once done, make sure there are not (other) repository configurations left in /etc/yum.repos.d related to eduVPN.

Updating#

Make sure your system is fully up to date on EL 9 and all configurations updated:

$ sudo vpn-maint-update-system
$ sudo vpn-maint-apply-changes

Now reboot the system:

$ sudo reboot

Make sure everything still works, i.e. login to the portal, and connecting to the VPN. If it does NOT, fix that first. There’s no point in continuing if your system is broken.

CPU Check#

In order to make sure your (virtual) CPU is supported by EL 10, check that it supports the x86_64-v3 features:

$ /usr/lib64/ld-linux-x86-64.so.2 --help | grep x86-64-v3
  x86-64-v3 (supported, searched)

If it does NOT show that output, you may need to update your (virtual) CPU first. Technically it is possible to run AlmaLinux 10 on a x86_64-v2 CPU, but we do not support that.

Upgrade#

Now that your system is in a good place to start the upgrade to EL 10, we’ll use ELevate to perform the upgrade.

The instructions to follow can be found here. We’ll replicate them below, but please make sure you also read the official instructions as things may change (slightly) over time.

Install the required packages:

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

Perform the preupgrade check:

$ sudo leapp preupgrade

Once this step finished, you’ll see a short summary of what was found. In our case:

============================================================
                      REPORT OVERVIEW                       
============================================================

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

HIGH and MEDIUM severity reports:
    1. GRUB2 core will be automatically updated during the upgrade
    2. Packages not signed by Red Hat found on the system
    3. Detected custom leapp actors or files.
    4. Leapp detected a processor which is no longer maintained in RHEL 10.
    5. Berkeley DB (libdb) has been detected on your system

Reports summary:
    Errors:                      0
    Inhibitors:                  1
    HIGH severity reports:       4
    MEDIUM severity reports:     1
    LOW severity reports:        2
    INFO severity reports:       1

Before continuing, review the full report below for details about discovered problems and possible remediation instructions:
    A report has been generated at /var/log/leapp/leapp-report.txt
    A report has been generated at /var/log/leapp/leapp-report.json

============================================================
                   END OF REPORT OVERVIEW                   
============================================================

You can look at the /var/log/leapp/leapp-report.txt file in order to figure out what are the “Inhibitors” that prevent you from upgrade. In our case it was the legacy network configuration, probably because of cloud-init. The fix for that is provided in the text file as well. We had to run a variation of the nmcli connection migrate command.

Now that you (hopefully) resolved the “Inhibitors”, it is time to start the upgrade itself and reboot after it completes. Make sure you keep an eye on the output:

$ sudo leapp upgrade
$ sudo reboot

It may take quite a while to complete, but eventually you should be able to login to your system again.

Post Upgrade#

Once you are back in, we’ll update the VPN server packages. They were NOT updated as part of the upgrade process:

$ sudo vpn-maint-update-system 

Also make sure we can still run “apply changes”:

$ sudo vpn-maint-apply-changes

In our case this failed because the openvpn command was broken:

$ openvpn
openvpn: symbol lookup error: openvpn: undefined symbol: EVP_MD_CTX_get_size_ex, version OPENSSL_3.4.0

This is because the EPEL repository configuration used during upgrade points to 10 and not 10.0. The difference is that 10 contains packages built for a the future 10.1 release and apparently breaks the ABI.

In any case, we can use dnf to fix it and make sure the installed packages are correct for the currently installed EL version:

$ sudo dnf distro-sync

Now, you can run “apply-changes” and it should complete without any errors:

$ sudo vpn-maint-apply-changes

Now you can figure out which (old) packages are still lingering on your system and remove them if you want. In our test there were just some old EL 9 kernels left and a few leapp packages.

$ rpm -aq | grep el9

You can also remove packages now that are no longer needed:

$ sudo dnf autoremove

The upgrade process set SELinux in permissive mode:

$ sestatus
...
Current mode:                   permissive
...

Modify /etc/sysconfig/selinux and set the SELINUX key to enforcing, i.e.:

SELINUX=enforcing

We also need to (re)enable a SELinux bool for OpenVPN in order to allow it to run the client-connect and client-disconnect scripts:

$ sudo setsebool -P openvpn_run_unconfined=on
$ sudo vpn-maint-apply-changes

Now reboot your system. Everything should come back properly. Test your VPN portal and try to enable the VPN to the server. That’s all!