Adventures in leapp upgrade – upgrading a CentOS 7 Virtualmin server to AlmaLinux 9

Notes on trying to upgrade an old CentOS 7 Virtualmin server using leapp . The point is to keep Virtualmin going and end up with AlmaLinux 9. This is risky and turned out to be an arduous process.

It’s a two step process as per the AlmaLinux website: https://wiki.almalinux.org/elevate/ELevate-quickstart-guide.html#upgrade-steps

Part one – Upgrading from CentOS 7 to AlmaLinux 8

The answer file problem helped here:

sudo leapp answer --section remove_pam_pkcs11_module_check.confirm=True

Assholes Redhat have information behind a paywall:

https://access.redhat.com/solutions/6971716

But if you read the log file you’ll see the problem at the top about the Kernel driver:

Had to rmmod floppy

After that a lot of time was spent on dnf that couldn’t update packages, which had to be removed one by one.

Eventually Python bombed.

Inhibitors are the ones to avoid. For example:

Upgrade has been inhibited due to the following problems:
1. Leapp detected loaded kernel drivers which have been removed in RHEL 8. Upgrade cannot proceed.

The output is here:

:/root]> head -n6 /var/log/leapp/leapp-report.txt
Risk Factor: high (inhibitor)
Title: Leapp detected loaded kernel drivers which have been removed in RHEL 8. Upgrade cannot proceed.
Summary: Support for the following RHEL 7 device drivers has been removed in RHEL 8:
- pata_acpi
- floppy

This happened after the reboot. So we can do this:

rmmod pata_acpi
rmmod floppy

and then try again. I tried around 8 times and eventually realized you have to wait a very long time after reboot before things happen.

Clean up after upgrade from 7 to 8

There are these instructions in the upgrade guide:

After reboot, login to the system and check how the upgrade went. Verify that the current OS is the one you need. Check logs and packages left from the previous OS version, consider removing or updating them manually.

cat /etc/redhat-release
cat /etc/os-release
rpm -qa | grep el7 
cat /var/log/leapp/leapp-report.txt
cat /var/log/leapp/leapp-upgrade.log

Let’s remove the manual labour via a script:

#!/bin/bash

# List all installed RPMs with 'el7' and store them in an array
packages=$(rpm -qa | grep el7)

# Check if any packages were found
if [ -z "$packages" ]; then
echo "No 'el7' packages found."
exit 0
fi

# Loop through each package and remove it
echo "The following 'el7' packages will be removed:"
echo "$packages"

read -p "Are you sure you want to proceed? (y/n): " confirm

if [[ "$confirm" =~ ^[Yy]$ ]]; then
for package in $packages; do
echo "Removing $package..."
yum remove -y "$package"
done
echo "All 'el7' packages have been removed."
else
echo "Operation canceled."
fi

Ironically after changing this, you still have  this:

rpm -qa | grep el7
leapp-upgrade-el7toel8-0.21.0-2.el7.elevate.3.noarch
python2-leapp-0.18.0-1.el7.noarch
leapp-0.18.0-1.el7.noarch

Then do this:

Navigate to the /etc/ directory and use an editor of your choice to edit the yum.conf file. You need to remove everything from the exclude line especially that refers to elevate or leapp.

#An example of yum.conf file:
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
best=True
skip_if_unavailable=False
exclude=python2-leapp,snactor,leapp-upgrade-el7toel8,leapp

Run the script again.

They repeat the same instructions for mc -e /etc/dnf/dnf.conf but I couldn’t find anything in there.

You can also check for the packages left from the upgrade process and remove them:

rpm -qa | grep elevate
rpm -qa | grep leapp

Then:

sudo rm -fr /root/tmp_leapp_py3

Then:

sudo dnf clean all

The next step says list RSA/SHA1 GPG keys, and delete this:

rpm -q gpg-pubkey --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n'

However, I have too many and they don’t give instructions so I ignore removing keys:

rpm -e [keyname]

Part two – Upgrading from AlmaLinux 8 to AlmaLinux 9

Next, we do the upgrade from 8 to 9.

First:

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

Then:

sudo yum install -y leapp-upgrade leapp-data-almalinux

Then:

sudo leapp preupgrade

Next we are stuck here:

============================================================
ERRORS
============================================================

2024-11-17 09:49:51.420062 [ERROR] Actor: network_manager_connection_scanner
Message: Failed to read NetworkManager connections
sudo nmcli connection show
sudo: nmcli: command not found

Fix

dnf install NetworkManager

Next we have this:

Upgrade has been inhibited due to the following problems:
1. Current x86-64 microarchitecture is unsupported in RHEL9
2. Detected RPMs with RSA/SHA1 signature

We change the host from KVM64 to host and now the upgrade proceeds and we only have the RSA/SHA1 signature problem.

head -n20 /var/log/leapp/leapp-report.txt

 The list of problematic packages:
- virtualmin-release (RSA/SHA1, Wed 26 Jul 2017 09:06:08 AM SAST, Key ID d9f9010760d62a6b)
- wbm-php-pear (RSA/SHA1, Mon 01 May 2017 06:43:02 AM SAST, Key ID d9f9010760d62a6b)
- perl-Term-Spinner-Color (RSA/SHA1, Tue 22 Aug 2017 01:11:50 PM SAST, Key ID d9f9010760d62a6b)

We locate these packages (without their depends but should really, see later):

rpm -q virtualmin-release
rpm -q wbm-php-pear
rpm -q perl-Term-Spinner-Color

 

Next

> sudo dnf remove virtualmin-release wbm-php-pear perl-Term-Spinner-Color
...
Removing:
perl-Term-Spinner-Color noarch 0.05-1 @System 42 k
virtualmin-release noarch 6.0-3.gpl @System 6.4 k
wbm-php-pear noarch 2:1.6-1 @System 49 k
Removing dependent packages:
virtualmin-config noarch 6.0.31-1 @System 166 k

...

Remove 4 Packages

Freed space: 264 k
Is this ok [y/N]:

This should be fine. This system is already on Virtualmin 7.

Finally

sudo leapp upgrade

 

Tags

Share this article

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to Top