v 1.2.4 fails to upgrade

[ManfredLan]

Hi,

I'm using this script since beta on our systems, with varying degree of success, but 1.2.4 is really a piece of work.

First of all, for some reason it does not recognize conflicting packagesduring the earlier stages of the checks until it suddenly during the third time notices: Datei /etc/nagios aus der Installation von nagios-nrpe-3.2.1-2.2.x86_64 kollidiert mit der Datei aus dem Paket nagios-common-4.4.9-1.el8.x86_64 Datei /etc/nagios aus der Installation von nagios-plugins-plesk-0.6-3.2.noarch kollidiert mit der Datei aus dem Paket nagios-common-4.4.9-1.el8.x86_64

I was able to mitigate by removing those packages, but still, a waste of time. Secondly, and that's the way more annoying, the actual upgrade process after the first reboot fails with the message that the repositories "extra" and "extra-source" are multiple times configured:

Which is not true from what I see from the feedback I created beforehand:

centos2alma_feedback.zip

Oh yeah and after the failed upgrade the server did boot bute well, this is what happened when I tried to create asecond feedback archive:

[SandakovMM]

Hello @ManfredLan,

First of all, for some reason it does not recognize conflicting packagesduring the earlier stages of the checks until it suddenly during the third time notices:

The tool did not check for any conflicting packages on the system before calling leapp. It has a list of known conflicting packages and removes them during the preparation stage. I will add nagios-nrpe and nagios-plugins-plesk to the list to solve the problem.

Secondly, and that's the way more annoying, the actual upgrade process after the first reboot fails with the message that the repositories "extra" and "extra-source" are multiple times configured:

The issue seems to have occurred within the temporary container which we unfortiantly can't control on centos2alma side. It appears to be linked to a problem with leapp or may have been caused by a missing libssl. Your repository configuration seems fine. However, since the feedback archive does not include leapp related configurations (/etc/leapp/files), it's unclear if mapping repositories was configured correctly

this is what happened when I tried to create asecond feedback archive

We should have yum available on both CentOs7 and AlmaLinux 8. I believe AlmaLinux maintains yum for backward compatibility. I could only assume the issue persists because the feedback was prepared inside a temporary container.