search

oamg / leapp-repository

Leapp repositories containing actors for the Leapp framework (https://github.com/oamg/leapp). Currently provides leapp repositories for in-place upgrades of RHEL systems.
Apache License 2.0
48 stars 144 forks source link

leapp upgrade does not respect --target version #1244

Closed xiphl closed 3 months ago

xiphl commented 3 months ago

I'm doing the leapp inplace upgrade on a existing RHEL7.9 VM to RHEL8. when running leapp upgrade with --target 8.8, I expected the upgrade to finish at rhel8.8 and not the latest rhel OS (8.10). I am running this upgrade inside a airgapped environment, with the redhat repositories available in internal repositories. command used: leapp upgrade --no-rhsm --enablerepo XX --enablerepo YY --target 8.8 is there anything i can do to debug?

To Reproduce The leapp libraries installed: leapp.noarch 0.17.0-1.el7_9 leapp-deps.noarch 0.17.0-1.el7_9 leapp-upgrade-el7toel8.noach 0.20.0-2.el7_9 leapp-upgrade-el7toel8-deps.noach 0.20.0-2.el7_9

pirat89 commented 3 months ago

Hi @xiphl xiphl, that's expected behaviour. First, it's not true that leapp does not respect the target 8.8 in this case. It always respect the value. If you check logs, I am sure you find 8.8 several times. Including --releasever 8.8. The problem you refer to is that custom repositories that have been manually required to be used during the upgrade has actually 8.10 content.

In this case, user has full responsibility for the content inside given repositories. If you want to ensure about the behaviour, check the logs to see what release has been set when calling DNF command. Feel free to reopen the ticket if you find that we call dnf with --releasever 8.10 when leapp is executed with --target 8.8 option.

Closing the issue.

xiphl commented 3 months ago

Hi @pirat89 , Thanks for explaining. Can I ask if you have any suggestions for workarounds in this kind of situation, like patching the actor scripts?

pirat89 commented 3 months ago

Well, the only thing you can do is to deliver repositories with valid expected content. That's why we do not do any other checks. Partially, you could check /etc/system-release inside the created target userspace container under /var/lib/leapp/el*userspace/ , however it's incomplete check. As history showed to us already, people are mixing also repositories for various target releases wihch leads to another unexpected issues. Also such a check would limit pre-release testing too. So from this point we decided to not implement this partial check neither as it's not reliable and provides additional problems.

The only reliable solution is to keep it on users, as users must naturally know what repositories they are using as they created them. if I create my custom repositories and I would like to be sure I am using valid content, I would store them under rhel-X.Y path and I would include such a substring in the repoid. So I would have double check I am using correct repositories.