Elevate Alma 8 to Alma 9 failed

After trying to Elevate/Migrate Alma 8.10 to Alma 9.X the “leapp preupgrade” failed with:
Check completed.
====> * 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 OVERVIEW

HIGH and MEDIUM severity reports:
1. Packages not signed by Red Hat found on the system

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

Before continuing consult the full 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 OVERVIEW

Answerfile has been generated at /var/log/leapp/answerfile
[root@PhxKvmSrv3 ~]#
[root@PhxKvmSrv3 ~]#
[root@PhxKvmSrv3 ~]#
[root@PhxKvmSrv3 ~]#

Hi, How can I get rid of that High Risk Factor from:
[root@PhxKvmSrv3 ~]# cat /var/log/leapp/leapp-report.txt
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:

  • elevate-release
  • leapp
  • leapp-data-almalinux
  • leapp-deps
  • leapp-upgrade-el8toel9
  • leapp-upgrade-el8toel9-deps
  • python3-leapp
    Key: 13f0791ae5f19f50e7d0d606fb6501f91b1efb2c

Risk Factor: low
Title: Some enabled RPM repositories are unknown to Leapp
Summary: The following repositories with Red Hat-signed packages are unknown to Leapp:

  • InstallMedia-AppStream
  • InstallMedia-BaseOS
    And the following packages installed from those repositories may not be upgraded:
  • virtio-win
  • abattis-cantarell-fonts
  • perl-Text-ParseWords
  • glusterfs
  • libepoxy
  • libgcab1
  • brotli
  • man-db
  • perl-Pod-Usage
  • spice-gtk3
  • perl-podlators
  • python3-webencodings
  • nettle
  • ima-evm-utils
  • perl-Digest
  • gpm-libs
  • osinfo-db-tools
  • perl-URI
  • perl-libnet
  • lua-libs
  • tpm2-tools
  • perl-IO-Socket-IP
  • crontabs
  • setroubleshoot-plugins
  • keyutils
  • lshw
  • perl-Data-Dumper
  • keyutils-libs
  • dejavu-fonts-common
  • dejavu-sans-mono-fonts
  • libfprint
  • libsmbios
  • glusterfs-client-xlators
  • spice-server
  • perl-Time-Local
  • libxmlb
  • glusterfs-cli
  • os-prober
  • libcap-ng
  • libxkbcommon-x11
  • libndp
  • perl-Pod-Simple
  • fontconfig
  • python3-ply
  • bubblewrap
  • libdb
  • libjpeg-turbo
  • scrub
  • perl-Term-Cap
  • python3-pyOpenSSL
  • gsettings-desktop-schemas
  • perl-Pod-Perldoc
  • perl-Pod-Escapes
  • spice-glib
  • glusterfs-libs
  • python3-psutil
  • glusterfs-api
  • perl-Encode
  • libxslt
  • perl-MIME-Base64
  • lz4-libs
  • mtdev
  • hdparm
  • libmodulemd1
  • libsmi
  • lsscsi
  • popt
  • libgovirt
  • soundtouch
  • python3-html5lib
  • perl-File-Temp
  • virt-who
  • libxcrypt
  • quota-nls
  • libdb-utils
  • perl-Term-ANSIColor
  • dconf
  • perl-Storable
  • libpcap
  • libsepol
  • jasper-libs
  • pango
  • parted
  • efi-filesystem
  • libmodulemd
  • fprintd
  • fprintd-pam
  • libvisual
  • libwacom-data
  • perl-Getopt-Long
  • python3-pexpect
  • libwacom
  • librelp
  • quota
  • userspace-rcu
  • python3-ptyprocess
  • pcre
  • perl-Digest-MD5
  • libevdev
    Remediation: [hint] You can file a request to add this repository to the scope of in-place upgrades by filing a support ticket
    Key: 8e89e20c645cea600b240156071d81c64daab7ad

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.3
Key: 01986584e27e85ea18929586faf614eee011a121

Risk Factor: info
Title: The upgrade will prepend the Include directive to OpenSSH sshd_config
Summary: OpenSSH server configuration needs to be modified to contain Include directive for the RHEL9 to work properly and integrate with the other parts of the OS. The following snippet will be added to the /etc/ssh/sshd_config during the ApplicationsPhase: Include /etc/ssh/sshd_config.d/*.conf
Key: 96da6937c25c6492e4f1228ee146795989fd3718

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

[root@PhxKvmSrv3 ~]#

thanks

Christian

If you have Errors: 0 and Inhibitors: 0, it usually means that it’s OK to ignore the warnings, and proceed with the upgrade using leapp upgrade.

Hi Norinori, Please take a look at attached server console snapshot showing the “leapp upgrade”

thanks

Christian

I have seen a few similar issues myself.
My fix was to run the command poweroff here, wait for shutdown, and then power on.
This solved it for me.

I have seen this type of problem on OS’s that were previously upgraded from CentOS 7, and there was not enough space in /boot, and no uefi config but legacy instead.

Hope this helps…

I tried that Poweroff/On, and system went back to previous Grub option which is Alma8.10.

The screenshot shows Alma 9, not Alma 8.
If you can’t resolve the boot problem, you may need to restore the machine from backup (go back to pre-migration), and inspect the disk/partition layout and grub config.

Yes, screenshot shows Alma9 telling that “leapp upgrade” seems to be OK., this output is from the “dracut” OS that the system ends up after the Mount problem on /home1/datastore1/ seeing there.
my question/concern is the following from Alma8.10:
[root@PhxKvmSrv3 ~]# mount | grep home
/dev/mapper/cl_phxkvmsrv3-home on /home type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/md126p1 on /home2/datastore2 type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota,x-parent=f10a511b:35704f15:ff08774c:0262697c)
/dev/sdc on /home/datastore1 type ext4 (rw,relatime)
[root@PhxKvmSrv3 ~]#

Could be “ext4” the issue here preventing the Elevation/Migration from Alma8.10 to Alma9.3, pls le me know any comments.

Regards,

Christian