AL 8.7 -> 9.1 using leapp

Hi folks. Has anybody used leapp to upgrade properly from 8.x to 9.1? I’m trying that now and it appears Redhat or leapp has some subscription-managerissues that this OS doesn’t recognize.

	--------------------------------------------------------------------------------
	Total                                           3.0 MB/s | 881 MB     04:58
	Running transaction check
	suTransaction check succeeded.do reboot now
	caRunning transaction testt /etc/os-release
	The downloaded packages were saved in cache until the next successful transaction.
	You can remove cached packages by executing 'dnf clean packages'.

	STDERR:
	warning: Found bdb_ro Packages database while attempting sqlite backend: using bdb_ro backend.
	No matches found for the following disable plugin patterns: subscription-manager
	Repository appstream is listed more than once in the configuration
	Repository appstream-debuginfo is listed more than once in the configuration
	Repository appstream-source is listed more than once in the configuration
	Repository baseos is listed more than once in the configuration
	Repository baseos-debuginfo is listed more than once in the configuration
	Repository baseos-source is listed more than once in the configuration
	Repository extras is listed more than once in the configuration
	Repository extras-debuginfo is listed more than once in the configuration
	Repository extras-source is listed more than once in the configuration
	warning: Found bdb_ro Packages database while attempting sqlite backend: using bdb_ro backend.
	Warning: Package marked by Leapp to upgrade not found in repositories metadata: python3-leapp leapp
	warning: Found bdb_ro Packages database while attempting sqlite backend: using bdb_ro backend.
	Error: Transaction test error:
		file /usr/lib64/engines-3/afalg.so from install of openssl-libs-1:3.0.7-6.el9_2.x86_64 conflicts with file from package openssl3-libs-3.0.7-5.el8.1.x86_64
		file /usr/lib64/engines-3/capi.so from install of openssl-libs-1:3.0.7-6.el9_2.x86_64 conflicts with file from package openssl3-libs-3.0.7-5.el8.1.x86_64
		file /usr/lib64/engines-3/loader_attic.so from install of openssl-libs-1:3.0.7-6.el9_2.x86_64 conflicts with file from package openssl3-libs-3.0.7-5.el8.1.x86_64
		file /usr/lib64/engines-3/padlock.so from install of openssl-libs-1:3.0.7-6.el9_2.x86_64 conflicts with file from package openssl3-libs-3.0.7-5.el8.1.x86_64
		file /usr/lib64/libcrypto.so.3.0.7 from install of openssl-libs-1:3.0.7-6.el9_2.x86_64 conflicts with file from package openssl3-libs-3.0.7-5.el8.1.x86_64
		file /usr/lib64/libssl.so.3.0.7 from install of openssl-libs-1:3.0.7-6.el9_2.x86_64 conflicts with file from package openssl3-libs-3.0.7-5.el8.1.x86_64
		file /usr/lib64/ossl-modules/fips.so from install of openssl-libs-1:3.0.7-6.el9_2.x86_64 conflicts with file from package openssl3-libs-3.0.7-5.el8.1.x86_64
		file /usr/lib64/ossl-modules/legacy.so from install of openssl-libs-1:3.0.7-6.el9_2.x86_64 conflicts with file from package openssl3-libs-3.0.7-5.el8.1.x86_64
		file /usr/share/ruby/irb from install of rubygem-irb-1.3.5-160.el9_0.noarch conflicts with file from package ruby-irb-2.5.9-110.module_el8.6.0+3074+4b08f9d4.noarch



	============================================================
												 END OF ERRORS
	============================================================


	Debug output written to /var/log/leapp/leapp-upgrade.log

	============================================================
														 REPORT
	============================================================

	A report has been generated at /var/log/leapp/leapp-report.json
	A report has been generated at /var/log/leapp/leapp-report.txt

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

	Answerfile has been generated at /var/log/leapp/answerfile
	2023-05-17 15:33:10.770 ERROR    PID: 6049 leapp: Upgrade workflow failed, check log for details

I thought I’d give it a try, but twice now, same errors. Should I just bite the bullet and do a fresh install of 9.1 current?

Here is a sudo leapp preupgrade:

	Transaction Summary
	=========================================================================================================================
	Install    152 Packages
	Upgrade    743 Packages
	Remove      47 Packages
	Downgrade    3 Packages

	Total size: 947 M
	Total download size: 881 M
	Downloaserver_d Packages:
	Check completed.
	====> * target_userspace_crypto_policies
					Set crypto policies inside the target userspace container.
	====> * tmp_actor_to_satisfy_sanity_checks
					The actor does NOTHING but satisfy static sanity checks
	====> * report_set_target_release
					Reports information related to the release set in the subscription-manager after the upgrade.
	====> * check_initramfs_tasks
					Inhibit the upgrade if conflicting "initramfs" tasks are detected
	==> Processing phase `Reports`
	====> * verify_check_results
					Check all dialogs and notify that user needs to make some choices.
	====> * verify_check_results
					Check all generated results messages and notify user about them.

	Debug output written to /var/log/leapp/leapp-preupgrade.log

	============================================================
														 REPORT
	============================================================

	A report has been generated at /var/log/leapp/leapp-report.json
	A report has been generated at /var/log/leapp/leapp-report.txt

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

	Answerfile has been generated at /var/log/leapp/answerfile
sudo cat /var/log/leapp/leapp-report.txt

	Risk Factor: high
	Title: Leapp could not identify where GRUB core is located
	Summary: We assume GRUB core is located on the same device as /boot. Leapp needs to update GRUB core as it is not done automatically on legacy (BIOS) systems.
	Remediation: [hint] Please run "grub2-install <GRUB_DEVICE> command manually after upgrade
	Key: ca7a1a66906a7df3da890aa538562708d3ea6ecd
	----------------------------------------
	Risk Factor: high
	Title: Packages not signed by Red Hat found on the system
	Summary: The following packages have not been signed by Red Hat and may be removed during the upgrade process in case Red Hat-signed packages to be removed during the upgrade depend on them:
	- ImageMagick
	- ImageMagick-libs
	- atop
	- caca-utils
	- catimg
	- certbot
	- chromedriver
	- chromium
	- chromium-common
	- ck
	- epel-release
	- gpg-pubkey
	- htop
	- imlib2
	- leapp-data-almalinux
	- leapp-upgrade-el8toel9
	- leapp-upgrade-el8toel9-deps
	- libbsd
	- libcaca
	- libmd
	- libraqm
	- libsqlite3x
	- libsqlite3x-devel
	- luajit
	- minizip
	- minizip1.2
	- ncdu
	- neofetch
	- nginx-mod-http-passenger
	- nss-mdns
	- openssl3
	- openssl3-devel
	- openssl3-libs
	- passenger
	- pgbouncer
	- python-josepy-doc
	- python3-acme
	- python3-beautifulsoup4
	- python3-certbot
	- python3-certbot-nginx
	- python3-colorama
	- python3-configargparse
	- python3-cssselect
	- python3-josepy
	- python3-parsedatetime
	- python3-pyrfc3339
	- python3-requests-toolbelt
	- python3-termcolor
	- python3-zope-component
	- python3-zope-event
	- python3-zope-interface
	- rubygem-rack
	- sysbench
	- tldr
	Key: 13f0791ae5f19f50e7d0d606fb6501f91b1efb2c
	----------------------------------------
	Risk Factor: high
	Title: An installed web server might not be upgraded properly.
	Summary: A web server is present on the system. Depenserver_d on the source of installation,  it may not upgrade to the new version correctly, since not all installation configurations are currently supported by Leapp. Failing to upgrade the webserver may result in it malfunctioning after the upgrade process finishes. Please review the list of packages that won't be upgraded in the report. If the web server packages are present in the list of packages that won't be upgraded, expect the server to be non-functional on the post-upgrade system. You may still continue with the upgrade, but you'll need to upgrade the web server manually after the process finishes. Detected webserver: NGINX.
	Key: d4ef1dc14e8a605d42c18940be65b9645b54f992
	----------------------------------------
	Risk Factor: high
	Title: Usage of deprecated class "Tags" at /etc/leapp/repos.d/system_upgrade/common/actors/checkgrubcore/actor.py:52
	Summary: The primitive is deprecated as Tags and Flags have been joined into the Groups primitive.Please use Groups for report message typing instead.
	Since: 2022-08-23
	Location: /etc/leapp/repos.d/system_upgrade/common/actors/checkgrubcore/actor.py:52
	Near:                     reporting.Tags([reporting.Tags.BOOT]),

	Key: 6d83d476441749a96937d77c68fa4f6137d15e0f
	----------------------------------------
	Risk Factor: high
	Title: Usage of deprecated class "Tags" at /etc/leapp/repos.d/system_upgrade/common/actors/redhatsignedrpmcheck/libraries/redhatsignedrpmcheck.py:24
	Summary: The primitive is deprecated as Tags and Flags have been joined into the Groups primitive.Please use Groups for report message typing instead.
	Since: 2022-08-23
	Location: /etc/leapp/repos.d/system_upgrade/common/actors/redhatsignedrpmcheck/libraries/redhatsignedrpmcheck.py:24
	Near:         reporting.Tags(COMMON_REPORT_TAGS)

	Key: b3b8d552a4464a2f0b0340e8798669b3e2af704f
	----------------------------------------
	Risk Factor: high
	Title: Usage of deprecated class "Tags" at /etc/leapp/repos.d/system_upgrade/common/actors/detectwebservers/actor.py:50
	Summary: The primitive is deprecated as Tags and Flags have been joined into the Groups primitive.Please use Groups for report message typing instead.
	Since: 2022-08-23
	Location: /etc/leapp/repos.d/system_upgrade/common/actors/detectwebservers/actor.py:50
	Near:                         reporting.Tags.SERVICES

	Key: b27033737477fc7e99878516fc9a3d9d1f72e68b
	----------------------------------------
	Risk Factor: high
	Title: Usage of deprecated class "Tags" at /etc/leapp/repos.d/system_upgrade/common/actors/checkselinux/libraries/checkselinux.py:29
	Summary: The primitive is deprecated as Tags and Flags have been joined into the Groups primitive.Please use Groups for report message typing instead.
	Since: 2022-08-23
	Location: /etc/leapp/repos.d/system_upgrade/common/actors/checkselinux/libraries/checkselinux.py:29
	Near:                 reporting.Tags([reporting.Tags.SELINUX]),

	Key: 29599e259616a9931a9f2a26e34bc5e38af9aa5d
	----------------------------------------
	Risk Factor: high
	Title: Usage of deprecated class "Tags" at /etc/leapp/repos.d/system_upgrade/common/actors/checkselinux/libraries/checkselinux.py:47
	Summary: The primitive is deprecated as Tags and Flags have been joined into the Groups primitive.Please use Groups for report message typing instead.
	Since: 2022-08-23
	Location: /etc/leapp/repos.d/system_upgrade/common/actors/checkselinux/libraries/checkselinux.py:47
	Near:             reporting.Tags([reporting.Tags.SELINUX, reporting.Tags.SECURITY])

	Key: 1763f7e8bdfd709914d3cf2c0116987d321a92ce
	----------------------------------------
	Risk Factor: high
	Title: Usage of deprecated class "Tags" at /etc/leapp/repos.d/system_upgrade/common/actors/reportsettargetrelease/libraries/reportsettargetrelease.py:45
	Summary: The primitive is deprecated as Tags and Flags have been joined into the Groups primitive.Please use Groups for report message typing instead.
	Since: 2022-08-23
	Location: /etc/leapp/repos.d/system_upgrade/common/actors/reportsettargetrelease/libraries/reportsettargetrelease.py:45
	Near:         reporting.Tags([reporting.Tags.UPGRADE_PROCESS]),

	Key: e27d31a8ba4ac71aee7f5a698e9538912cad7dc5
	----------------------------------------
	Risk Factor: low
	Title: The subscription-manager release is going to be kept as it is during the upgrade
	Summary: The upgrade is executed with the --no-rhsm option (or with the LEAPP_NO_RHSM environment variable). In this case, the subscription-manager will not be configured during the upgrade. If the system is subscribed and release is set already, you could encounter issues to get RHEL content using DNF/YUM after the upgrade.
	Remediation: [hint] Set the new release (or unset it) after the upgrade using subscription-manager: subscription-manager release --set 9.0
	Key: 01986584e27e85ea18929586faf614eee011a121
	----------------------------------------
	Risk Factor: info
	Title: LEAPP detected SELinux disabled in "/etc/selinux/config"
	Summary: On RHEL 9, disabling SELinux in "/etc/selinux/config" is no longer possible. This way, the system starts with SELinux enabled but with no policy loaded. LEAPP will automatically disable SELinux using "SELINUX=0" kernel command line parameter. However, Red Hat strongly recommends to have SELinux enabled
	Key: a32598d132c02dc20fd3daf631e85770623d3f8e
	----------------------------------------
	Risk Factor: info
	Title: SElinux disabled
	Summary: SElinux disabled, continuing...
	Key: 4f25fea9b15b9d1d07d52cc1de02073f295dac3d
	----------------------------------------

are you talking about pure rhel leapp or do you mean almalinux elevate?

i’ve used elevate to do loads of alma/centos8 to alma9 migrations, not rhel though. and it’ll go to 9.2 now not 9.1

your issue looks like you’ve installed packages from various unsupported repo’s - how you’ve got openssl3 running on rhel 8 is anyone’s guess lol.

Well, the latter. Only by online advice, I went down that route. Didn’t work.

As I posted, there was no 9.2 that showed up.

I will try this as it’s apparently easier than…days ago. Or maybe I should wait 72 hours. Heh.

So it’s reporting 8.7 (see below) won’t go to 9.x, due to version errors

	Upgrade has been inhibited due to the following problems:
    1. Inhibitor: The installed OS version is not supported for the in-place upgrade to the target RHEL version
	Consult the pre-upgrade report for details and possible remediation.

Here’s what I thought might be relevant, as the file is massive:

	2023-05-19 17:19:36.423 INFO     PID: 5891 leapp.workflow.Checks: Executing actor check_ipa_server
	2023-05-19 17:19:36.504 INFO     PID: 5891 leapp.workflow.Checks: Executing actor check_os_release
	2023-05-19 17:19:36.568 INFO     PID: 5891 leapp.workflow.Checks: Executing actor check_skip_phase
	2023-05-19 17:19:36.637 INFO     PID: 10513 leapp.workflow.Checks.check_skip_phase: An upgrade inhibitor detected. Skipping to the Report phase.
	2023-05-19 17:19:36.644 INFO     PID: 5891 leapp.workflow: SkipPhasesUntilCommand received. Skipping phases until targettransactioncheck
	2023-05-19 17:19:36.646 INFO     PID: 5891 leapp.workflow.Checks: Starting stage After of phase Checks
	2023-05-19 17:19:36.648 INFO     PID: 5891 leapp.workflow: Skipping phase TargetTransactionFactsCollection
	2023-05-19 17:19:36.649 INFO     PID: 5891 leapp.workflow: Skipping phase TargetTransactionCheck
	2023-05-19 17:19:36.650 INFO     PID: 5891 leapp.workflow: Starting phase Reports
	2023-05-19 17:19:36.651 INFO     PID: 5891 leapp.workflow.Reports: Starting stage Before of phase Reports
	2023-05-19 17:19:36.652 INFO     PID: 5891 leapp.workflow.Reports: Starting stage Main of phase Reports
	2023-05-19 17:19:36.653 INFO     PID: 5891 leapp.workflow.Reports: Executing actor verify_check_results
	2023-05-19 17:19:36.708 INFO     PID: 5891 leapp.workflow.Reports: Executing actor verify_check_results
	2023-05-19 17:19:36.793 INFO     PID: 5891 leapp.workflow.Reports: Starting stage After of phase Reports
	2023-05-19 17:19:36.795 INFO     PID: 5891 leapp.workflow: Workflow finished due to the until-phase flag
	2023-05-19 17:19:36.832 INFO     PID: 5891 leapp: Answerfile will be created at /var/log/leapp/answerfile

Any ideas?

Oh, it’s 8.8:

NAME="AlmaLinux"
VERSION="8.8 (Sapphire Caracal)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="8.8"
PLATFORM_ID="platform:el8"
PRETTY_NAME="AlmaLinux 8.8 (Sapphire Caracal)"
ANSI_COLOR="0;34"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:almalinux:almalinux:8::baseos"
HOME_URL="https://almalinux.org/"
DOCUMENTATION_URL="https://wiki.almalinux.org/"
BUG_REPORT_URL="https://bugs.almalinux.org/"

ALMALINUX_MANTISBT_PROJECT="AlmaLinux-8"
ALMALINUX_MANTISBT_PROJECT_VERSION="8.8"
REDHAT_SUPPORT_PRODUCT="AlmaLinux"
REDHAT_SUPPORT_PRODUCT_VERSION="8.8"

Do you know how fast something like this can resolve? This must have moved only recently.

you’ve got far too much non-standard stuff on there.

also you’re mentioning redhat a lot, you’re not trying alma 8.8 to rhel 9.2 are you?

…I appreciate your input. I am so curious about this…

What does ‘far too much’ entail? This is an nginx box with a couple of other items on it. It’s not a desktop in any way. It’s headless, minimal. I just want to know what’s considered ‘too much’.

This is a full AL machine. Any single reference to RH is from script returns. Only recently have I seem 8.7 change to 8.8, and the prebuild shows it stopping ONLY ON that versioning issue itself.

Ya, AL to AL all the way. I’m considering just rebuilding the box entirely, but this seems like it’s the route to replacing the OS with the very same infrastructure (outside of a sudo dnf/yum update -y post-upgrade).

I’m not adverse to either. My goal is to minimize confusion. I also don’t want a strong front box relying on a migrated box, if that slows things down, reduces integrity, etc. From the looks of it, this Elevate tool is very nice, and just replaces the base OS.

Can I get your insight as to the most simple way forward, in terms of a long term reliance? I have all my scripts, I know what packages I need to install, and a full set of notes.

I appreciate your time. Cheers

…and an edit from 8.8 -> 9.2. Heh.

47 non-AlmaLinux repo packages, i’d say is a lot, and by the looks of it, they’re all going to be removed, plus some ruby thing which looks like it’s been installed as a module (yuk!)

openssl3 on 8.8 is really weird, what does “dnf repolist” return - not just EPEL i expect?

did this start out as a RHEL box perhaps?

what commands are you running to do this, should be something like this (all as root):

yum update -y
reboot
yum install -y  https://repo.almalinux.org/elevate/elevate-release-latest-el8.noarch.rpm
yum install -y leapp-upgrade leapp-data-almalinux
leapp preupgrade

# if that looks ok then:
leapp upgrade
reboot

otherwise, if you have everything scripted and data backed up, i’d honestly rebuild straight to 9.2 - although note your scripts/config might need changing for al9 - try it in a vm or something first.

elevate (and even moreso, rhel leapp) has always come with the proviso of it might not work if you have non-standard packages (or will just remove them lol!)

Here’s that repolist:

repo id                                   repo name
appstream                                 AlmaLinux 8 - AppStream
baseos                                    AlmaLinux 8 - BaseOS
elevate                                   ELevate
elevate-testing                           ELevate Testing
epel                                      Extra Packages for Enterprise Linux 8 - x86_64
extras                                    AlmaLinux 8 - Extras
passenger                                 passenger

This started recently as a AL 8.x box. My notes say the following:

sudo yum update -y
sudo reboot now
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
sudo leapp preupgrade`

OK, sounds like a redo. Not that bad. Just new territory as usual. And time.

Out of curiosity, why would such restrictions validate the need for such a package (ELevate)? Updating a vanilla box from X to Y kind of defeats the point of a fresh install.

Cheers

you could just stick to al8, its got a couple of years left in it yet.

assuming this isn’t an important/production box, you could try reinstalling openssl 1.1.1 and removing 3.0.7 and that ruby module, that looks like it should at least let the transaction continue (not sure if it would remove the other 40-odd packages!)

you could try on the elevate chat too: AlmaLinux OS Foundation Chat

Too late. Heh.

Ya the items I need on this box. 9.2 in, I’m having some other ruby issues.

Moving right along. Thanks for your input.

1 Like