Description of problem: $subject. In particular, if a scriptlet fails, yum (usually?) considers this non-fatal, e.g. it might emit: Yum Non-fatal POSTIN scriptlet failure in rpm package $package and if such a failure happens when running yum from the command line, it will continue and finish its transaction. But if this happens inside otopi, otopi will rollback and abort. Personally, I am not sure this is such a bad behavior. One might claim, that for the intended use-case - automation of various setup processes in oVirt - it's reasonable to require that scriptlets do not fail, and if they do, we should debug and fix them not to, rather than allow continuing (thus more likely ignoring the failure). Main issue with this is IMO that it's confusing - that the output/log claims it was non-fatal and we still fail. This behavior seems to have been introduced by the following patch: https://gerrit.ovirt.org/10717 Seems like fixing this will not be very easy. I'll spend some more time looking. IMO we can close this bug. I mainly opened it for visibility/documentation.
Managed to prepare a fix, so moving to POST. I still think it's a risk. The logic to decide if a scriptlet should fail the installation or not seems to be in [1][2]. Meaning, if the error (rc!=0) is in one of the scriptlets %pre, %preun, %pretrans, or in Verify, we should fail, otherwise just say it's a non-fatal error. Should otopi adopt same behavior? Or keep existing, where every error from yum is fatal and causes otopi to rollback and abort? [1] https://github.com/rpm-software-management/rpm/blob/master/lib/transaction.c#L1455 [2] https://github.com/rpm-software-management/yum/blob/master/yum/rpmtrans.py#L610
(In reply to Yedidyah Bar David from comment #1) > Managed to prepare a fix, so moving to POST. > > I still think it's a risk. > > The logic to decide if a scriptlet should fail the installation or not seems > to be in [1][2]. And looks like the dilemma is still open also in yum: # FIXME - what else should we do here? raise a failure and abort? I would rather fail and rollback, I agree changing this is a risk and prefer to get scriptlet fixed instead of just ignore them.
Very well. Summary: If you run otopi (e.g. engine-setup, host-deploy, hosted-engine --deploy) and see something like that: Yum Non-fatal POSTIN scriptlet failure in rpm package $package Then: 1. you should likely see more errors later 2. otopi did fail, aborted, and rolled back changes it already did (or at least tried to), even though yum decided it's a "non-fatal" failure.