I migrated most of my Centos 7 and 8 boxes to version 8 of RHEL or Alma Linux. (Exception is on a box with Arch Linux running on an old Atom CPU which did not support RHEL8).
But the update from RHEL/Alma 8 to 9 has one big problem. leapp does not support installation with luks disks via the actor inhibitwhenluks and most of my machines have encryption enabled.
I wanted to test what the problem is. So I installed a VM with Alma Linux 8 and luks. Delete the actor inhibitwhenluks and try to run leapp. I expected an unbootable system or some strange problem, but nothing happened. It simply worked.
The default VM setting is still BIOS on Fedora, so maybe the problem only exists with UEFI. So I deleted the VM and reinstalled it with UEFI and Virt-SCSI as disc controller ( don’t forget to add a SCSI Controller type Virt-SCSI). Installed again with root on luks, run leapp. Again no problem.
So from my short test with 2 virtual machines, it worked better then the warning suggested. I can only explain it with an abundance of cautiousness on the Red Hat side and a simple copy of the files from Alma side. This also explains an error that prohibits the usage on the Alma side, because there is error that the kernel is not from Red Hat and upgrade is not finished.
This is what I did on RHEL and Alma:
- delete actor “prohibit luks”:
rm -rf /usr/share/leapp-repository/repositories/system_upgrade/common/actors/inhibitwhenluks
For Alma you need to allow non RedHat Kernel to be installed:
- remove abort in /usr/share/leapp-repository/repositories/system_upgrade/common/actors/kernel/checkinstalledkernels/libraries/checkinstalledkernels.py
sed -e 's:raise StopActorExecutionError:#raise StopActorExecutionError:g' /usr/share/leapp-repository/repositories/system_upgrade/common/actors/kernel/checkinstalledkernels/libraries/checkinstalledkernels.py
That fixed this problem, at least for me. Of course the other problems from the “leapp preuptrade” have to be handled. I only tested it with a fresh install. I will update my homeserver in the next couple of days/weeks/month.
P.S.: Don’t forget to cleanup old gpg Key that are using SHA1 to fix the problem with: “Hash algorithm SHA1 not available.”. I delete all gpg-pubkey packages, because yum will reinstall the needed keys anyway.
Hi, I’m a sysadmin in a similar situation as you. We have a physical server running CentOS 7 and want to migrate to Rocky Linux 8. I was following the steps laid out in this guide here (https://linuxiac.com/migrating-from-centos-7-to-rocky-linux-8/) but came across the issue of upgrading because the root partition of the drive is LUKS encrypted.
Would there be a similar way to remove the actor file from CentOS7 to allow for the upgrade to take place still?
Hi, I don’t have any RHEL 7 with crypto anymore. So I can not help you there. But it could work. But have a look at the crypto, because there were some bad crypto used as default for some time when it came to luks.