Linux Notes: leapp (migration tool)

  1. The information presented here is intended for educational use by qualified computer technologists.
  2. The information presented here is provided free of charge, as-is, with no warranty of any kind.
Edit: 2023-09-20
back to: my Linux Notes (index)
CAVEAT: Linux computer systems of any commercial value should be covered by a support contract (Red Hat is your obvious choice). The following information is very dangerous so should only be attempted by seasoned professionals working at colleges and universities, or hobbyists working or personal systems. And as always, make sure you have backup copies of everything before you begin.

Migrating Linux


Linux terminology: update vs. upgrade vs. migrate

  • any minor point change is known as an update (upgrade is the same as update with the --obsoletes flag set)
  • any major point change is known as migrate


  • leapp is an open-source migration tool created by Red Hat for their own use. The code is published on github
    • RHEL-leapp recipes are only available to RHEL customers via their private repos via their subscription manager ($$$)
    • not sure if they offer any magic scripts
  • Oracle adapted leapp for use with Oracle Linux
    • Oracle-leapp recipes are only available to systems already using Oracle Linux
      (so they offer a magic script to convert from CentOS-7 to Oracle Linux-7; then you use Oracle-leapp to migrate from 7 to 8, then 8 to 9)
      (this script failed badly on my lab system yesterday)
  • AlamaLinux adapted leapp for community use
    • Alma-leapp recipes are available via their ELevate project:
    • ELevate-leapp is also the safest way to migrate from CentOS-7 to CentOS Stream-8, then to CentOS Stream-9
    • so the safest way to move from CentOS-7 to Oracle Linux-8 is to use ELevate-leapp, then use Oracle-leapp to jump from 8 to 9


  • SUSE publishes SLES (comparable to RHEL), openSUSE leap (comparable to CentOS-8.5), openSUSE tumbleweed (comparable to CentOS Stream)
  • Last year they also published SUSE Liberty Linux: with tools to migrate from any version of RHEL to Liberty
  • SUSE and Oracle are now behind with something expected to be released before the end of this year (some have speculated that SUSE Liberty will appear here in a new form)
  • IMHO, most people on CentOS-7 at this time (2023-09-xx) should until we see what is published by OpenELA (and whether they get the seal of approval from Oracle Linux)

Linux terminology

update moving from CentOS-7.8 to CentOS-7.9
upgrade moving from CentOS-7.8 to CentOS-7.9 same as "update --obsoletes"
moving from CentOS-7.x to CentOS-8.x (or anything else)

Manual Methods (less safe)

  • We all have seen plenty of migration procedures published by various self-help sites.
  • The dozen I tested all worked with systems connected to the public internet.
  • I did not find a single procedure which worked from behind a proxy server.
  • I suspect that most will not stand the test of time as various repos move, and certificates expire (I had to tweak a few URLs in order to get some of them to work)
  • Anyway, these procedures appear fragile (the upgrade might fail whether you made a mistake or not). Once started, there is no clean back out procesure.

Notable Magic Scripts (less safe)


  • None of these scripts are 100% safe.
  • None offer a clean back out feature so could leave your system in an intermediate state if they hit an error.
  • If you must use them, then first perform a trial run on a scratch system.
  • Make backup copies of everything before you begin.
lateral transfer
from to CentOS-x AlmaLinux-x CentOS-8
Rocky Linux-8
Rocky Linux-9
( )
Oracle Linux-6
Oracle Linux-7
Oracle Linux-8
Oracle Linux-8
Oracle Linux-9

Orchestrated Method (safer)

  • leaap is an open-source migration tool created by a Red Hat, and intended for use by paying customers wishing to migrate from anything to RHEL.
  • If you are considering a jump to RHEL-8, then you had better talk to Red Hat who will provide a detailed procedures for use leapp. Many of the so-called recipes are only available from a Red Hat repo which sits behind a paywall (enabled via the Red Hat subscription manager)
  • AlmaLinux created the ELevate project (which is based upon leapp) for moving to almost every other rpm-based Linux. AlmaLinux recipes are provided free-of-charge.
  • Some rpm-based Linux distros also provide a  leapp-based procedure to help you migrate to their Linux offerings. Here is one for moving to Oracle Linux

ELevate - leapp (intro)

  • Moving from Enterprise Linux version 7 to 8 is a very big deal. Why? Here are a few major points:
    1. some v7 system tools, like yum and firewall-cmd, depend upon python2.7 which need to be updated to python3.6
    2. part way through, yum will be replaced with dnf
    3. caveat: if you own any third-party programs (or cgi scripts) which depend upon python2 then I suggest you rewrite them, or purchase python3 replacements before you migrate.
  • The neat thing about leapp is that it begins the upgrade in a private namespace. If anything fails in the namespace, then your system continues to work properly
    • the leapp preupgrade command will allow you to do no-commitment trials
      • do as many as you like
      • all the work is loaded into a namespace which is where the replacement software is built
      • uninstalling leapp will to free up most space allocated by leapp
        # uninstall leapp
        yum erase \*leapp\*
        # -----------------------------------------
        # OPTIONAL: very dangerous commands so type carefully
        rm -fr /var/lib/leapp/*
        rm -fr /var/log/leapp/*
    • the leapp upgrade command
      • may repeat some preupgrade steps, may goes further.
        • If it fails, then then "no permanent changes have been made to your system".
        • If it doesn't fail, then you are, more-or-less, committed to doing a reboot
          • the first GRUB entry on the boot menu contains hooks to continue the migration (this can fail so always pretest on a scratch server)
          • from the main console, you could still select the second entry which would take you to the your existing OS 
    • caveats:
      • leapp preupgrade will run at the level of the system you are migrating from (say, CentOS7)
      • leapp upgrade will run at the level of the the system you are migrating to (say, AlmaLinux8)
      • if you sit behind a proxy server then you will need to get that information to both layers (more on this in a moment)
  • General docs

CentOS-7 to AlmaLinux-8 (or something else)

  • The leapp procedures documented here work with systems connected to the public internet
  • I wanted to migrate from CentOS-7 to AlmaLinux-8 so decided to only play with Elevate-leapp
    • caveat: later on I did a trial conversion from CentOS-7 to Rocky-8 (which worked) followed by a conversion to Rocky-9 (which did not work)
  • The Elevate procedure from Alma did not work (as-is) from behind a proxy server on 2023-08-28, but I was able to develop a few workarounds that did work.
Playing it safe with trial converts
  1. steps:
    • grab a spare computer then do a fresh install of the OS you want to migrate from (I used CentOS-7.9)
    • connect it to the public internet
    • follow the Elevate procedure described here:
    • take notes about what you see AND how many times the system reboots (for this experiment it is important that you are physically located in front of the server's console device)
    • Note: I did a dozen trial conversions before I used leapp on a working server.
  2. repeat step-1 but on a system connected it to a network behind a proxy server
    • anyone who has ever used CentOS-7 already knows you need add 1-2 lines of additional information to file /etc/yum.conf
    • anyone who has ever used CentOS-8 already knows you need add 1-2 lines of additional information to file /etc/dnf/dnf.conf
    • so it should be no surprise that you may need to update various copies of dnf.conf in the leapp namespace
    • but one of those files will be overwritten several times when you run leapp
      • hack-1: requires you to update this file: /etc/leapp/files/leapp_upgrade_repositories.repo
        • insert this line into every labelled stanza: proxy=
        • optionally, also add this line in every labelled stanza: sslverify=false (this could be dangerous so only use thus if you see CURL (60) error messages)
      • hack-2: requires you to add proxy information to file /var/lib/leapp/el8userspace/etc/dnf/dnf.conf then also run a little script on a second session which will monitor the file then update it whenever it is overwritten (usually 4 times)
      • hack-3: requires you to copy your organization's certificates into the namespace
      • hack-1 works 99% of the time
      • hack-2 (with hack-1) was twice at a remote location. "I think" this might be due to a misconfiguration of my company's proxy server.
        • hack-1 is necessary for leapp preupgrade
        • hack-2 is necessary for leapp upgrade
      • I haven't yet tried hack-3
  3. repeat step-1 but use a backup copy of the server you wish to convert
  4. repeat step-2 but use a backup copy of the server you wish to convert and connect it to a network behind a proxy server
Details (for use behind a proxy sever)
  1. sudo yum update -y
    sudo reboot
    sudo yum install -y$(rpm --eval %rhel).noarch.rpm
    sudo yum install -y leapp-upgrade leapp-data-almalinux
  2. tweak-1
    # we we will do everything from root (so do not use sudo)
    # become root
    su -
    # changes to root's  shell
    # ------------------------
    # changes for leapp
    export LEAPP_PROXY_HOST=
    # changes for curl export http_proxy= export https_proxy= # # changes to your terminal emulator # --------------------------------- # set term to autowrap # set an ssh keepalive of 60 seconds
    # add proxy information to the ELevate repo
    vim /etc/leapp/files/
  3. leapp preupgrade
    • this should work with little difficulty
    • if you see errors then you will need to correct them
    • if you see inhibited then you may need to edit the answer file
  4. leapp upgrade (caveat: do not do this unless to intend to upgrade right now)
    • this works almost entirely in the target namespace
    • I have never had this phase go as-is:
      • in one case I was warned about multiple kernels so needed to remove them from CentOS then start over
      • in a second case I was warned about no available update for OpenSSL-devel which was version locked to OpenSSL which was going to be replaced
        • the solution was to yum erase OpenSSL-devel then restart leapp upgrade
      • in a third case I was warned about no available update for Make-devel which was version locked to Make which was going to be replaced
        • the solution was to yum erase Make-devel then restart leapp upgrade
    • If you see any "Curl (60)" errors then you will need to do the following ugly hack:
      • log into a second session; become root; execute my workaround script (see below)
      • repeat leapp upgrade on the primary session
  5. reboot
  6. wait 45-60 minutes then log in
    • be patient here; you may see console messages which indicate that the whole thing will fail, but then the upgrade continues ~ 600 seconds later
  7. vi /etc/dnf/dnf.conf
    1. comment out the exclude line
    2. add a proxy line
  8. yum erase \*leapp\*
  9. yum erase ELevate
My Trial Conversions
Date From To Method score To Method score notes
2023-08-31 CentOS-7.9 Rocky Linux-8.8 ELevate pass Rocky Linux 9.2 Elevate fails 1
2023-09-07 CentOS-7.9 AlmaLinux-8.8 ELevate pass AlmaLinux 9.2 Elevate dirty pass 2
2023-09-14 CentOS-7.9 Oracle Linux-8.8 ELevate pass Oracle Linux 9.2 Oracle Leapp pass 3
  1. Missing a file
    file /usr/share/redhat-logos from install of rocky-logos-90.14-1.el9.x86_64 conflicts with
    file from package rocky-logos-86.3-1.el8.x86_64
    # note: you cannot yum erase rocky-logos-86.3-1.el8.x86_64
  2. Rather than rebooting, the system comes up in Recovery Mode but no commands appear to work. The system boots properly after cycling the power.
    Note: checking the logs, I see a python error associated with main.cli
  3. No drama here. This worked like a charm
My workaround script

This hack was quickly written during a moment of frustration and panic
Only use this if you see failures associated with curl (60) errors.

# ================================================================
# title  : 
# author : Neil Rieck
# created: 2023-08-28
# notes  :
# 1) to be used during the leapp upgrade:
#	el="78" for CentOS-7 to AlmaLinux-8
#	el="89: for AlmaLinux-8 to AlmaLinux-9
# 2) run this on a second session while you upgrade from the first
# ================================================================
el="89"					# choices: "78" or "89"
if [[ ${el} == "89" ]]
    echo "for use with leapp 8-to-9"
    echo "for use with leapp 7-to-8"
echo "sslverify=0"                            >> ${fs}
echo "proxy=" >> ${fs}
prevModificationSeconds=$(date -r ${fs} +%s);           # snapshot 1
for (( ; ; ));
    echo "test: "${n}" changes: "${c}
    watchModificationSeconds=$(date -r ${fs} +%s);      # test
    if [[ ${prevModificationSeconds} != ${watchModificationSeconds} ]]
        echo "-i-oops, the file changed"
        echo "sslverify=0"                            >> ${fs} 
        echo "proxy=" >> ${fs} 
        prevModificationSeconds=$(date -r ${fs} +%s);   # snapshot 2
        echo "-i-update complete"
    sleep 1
echo "-i-exited"

 Back to Home
Neil Rieck
Waterloo, Ontario, Canada.