What were you trying to do that didn't work?

I'm filing this issue with Major severity because this issue creates a lot of load on support, especially on backline, and also because any customers suffer from this, creating delays in upgrade and usually creating a lot of frustration along with high pressure on both customer and RH side.

It appears that as soon as a grain of sand is present on the file system, the reboot phase will fail during the DNF transaction. Most of the time this could be avoided if leapp was executing the DNF transaction for real (in an overlay of course).

Typical cases were issue occurs:

1. a packaged file is immutable on the file system
2. a RPM scriptlet fails
   e.g. with emacs package, removing the alternative /etc/alternatives/emacs prior to upgrading makes the transaction fail
3. non-RH packages collide with RH packages

Please provide the package NVR for which bug is seen:

All leapp releases

How reproducible:

Always

Steps to reproduce

1. Install emacs package

   # yum -y install emacs

2. Delete the alternative

   # rm /etc/alternatives/emacs

3. Execute leapp upgrade then reboot

Expected results

Error being detected prior to rebooting.

Actual results

Reboot phase entering emergency prompt due to DNF transaction failure:

[ 337.289089] upgrade[606]: Failed:
[ 337.289162] upgrade[606]: emacs-1:24.3-23.el7_9.1.x86_64
[ 337.289236] upgrade[606]: Stderr: No matches found for the following disable plugin patterns: subscription-manager
[ 337.289383] upgrade[606]: Warning: Package marked by Leapp to upgrade not found in repositories metadata: leapp-upgrade-el7toel8 leapp python2-leapp
[ 337.289530] upgrade[606]: Error in PREUN scriptlet in rpm package emacs
[ 337.307682] upgrade[606]: Error: Transaction failed