Handling Faulty Package with %preun Scriptlet During Leapp Upgrade to RHEL 8

[perseptron]

I'm trying to upgrade my system to RHEL 8, but the process drops to the rescue prompt due to a faulty package. The issue is caused by a broken %preun scriptlet in that package, which prevents it from being upgraded. At the same time, I can't remove it before the upgrade because it's needed during the upgrade process.

To work around this, I wrote an actor that forcibly removes the package using rpm -e --noscripts, and I run this actor before the RPM Upgrade Phase. This removes the problematic package as intended. However, the new version of the package is not installed during the upgrade. It seems Leapp won't install the new version if the old version is missing from the system.

It looks like I’ll need to write a second actor to install the new version manually, but I'm not sure how to install a package from the cache during the initramfs stage of the upgrade.

Any guidance on how to correctly install a package from the cache during initramfs would be appreciated (or any other solutions to my problem).

[pirat89]

Hi @perseptron, in your case, removing such an rpm using rpm -e --noscripts before the upgrade transaction is possibly the only way to deal with the problem now - if the fix of the rpm is not possible anymore. As RHEL 7 is in ELP (ELS) phase, I expect that the buggy preun script is not going to be fixed (if we speak actually about a RHEL's rpm). However, note that the upgrade DNF transaction does not count with changes on the system after it's pre-calculated. So it has some limits - e.g. the one you hit that the target RPM is not automatically installed.

I expect that in your case the reason why the target RPM is not installed is because there is not explicit instruction for DNF to install this RPM, and originally it was planned automatically by DNF to install it as an update of the original installed one. Currently, even when trying to perform the upgrade transaction from cache, DNF recalculates the transaction again (which is good in this case, as the previous removal of an old RPM would lead to the fail of the transaction otherwise).

If you want to be sure that a specific target RPM is going to be installed, you have two options:

1. echo "rpmname" > /etc/leapp/transaction/to_install - before the leapp execution. This will tell leapp to request installation of a target RPM explicitly if it is available. So creating another actor would not be needed. (Note that in future for IPU 8 -> 9 this file will be replaced by a different config; but for IPU 7 -> 8 no other changes are planned.)
2. Create a separate actor which will instruct leapp to install the specific RPM during the upgrade transaction: such an actor should produce msg like this:

   api.produce(RpmTransactionTasks(to_install=['rpmname']))
   

   I suggest to produce it during the checks phase (ChecksPhaseTag)

Both ways are kind of equal, just in case you create your own actor you can make it conditional if you want. If you do not need to make it conditional, I would just update the config file as mentioned.

There are also other ways, like copy RPMs you want to install into the /usr/share/leapp-repository/repositories/system_upgrade/el7toel8/files/bundled-rpms directory before the leapp execution. But I think that in your case the first option is the one that you want. Focusing on the solution that the rpm is installed during the main DNF upgrade transaction instead of installing it separately in "post-upgrade" phases.

[perseptron]

Yes, the first option works for me. I just have to add full name of the package (with the version) to the "/etc/leapp/transaction/to_install"
Thank you very much for the detailed answer!

[pirat89]

Interesting. I really expected that name of the pkg would be enough. But it's possible that it is problematic for DNF (or we have maybe a filter?...) when trying to request an installation of a package by name when such a package is already installed. Using the NEVR instead could deal with it as it will be different from the installed one. Thanks for letting us know.