Hi, On Mon, Oct 28, 2019 at 3:04 PM Derek Atkins <derek@ihtfp.com> wrote:

Hi,

I spent yesterday trying to upgrade my self-hosted, single-host, ovirt engine from EL7.4/OV4.1.9 to EL7.7/OV4.3.x with a step at EL7.6/OV4.2.8. Unfortunately that first step was extremely problematic. Specifically, I kept hitting an issue where the installation ofovirt-vmconsole would error out with a "non-fatal POSTUN scriptlet failure", which of course is considered fatal:

Not sure if "of course" is sarcastic, but it's discussed in the referenced bug and a linked bug 1493160 which I opened myself and eventually closed notabug, deciding it's the safest option. If you disagree, please see that bug and feel free to comment/reopen/etc.

2019-10-27 10:42:18,436-0400 DEBUG otopi.plugins.otopi.packagers.yumpackager yum packager.verbose:76 Yum Done: ovirt-vmconsole 2019-10-27 10:42:18,504-0400 ERROR otopi.plugins.otopi.packagers.yumpackager yum packager.error:85 Yum Non-fatal POSTUN scriptlet failure in rpm package ovirt-vm console-1.0.4-1.el7.centos.noarch 2019-10-27 10:42:18,505-0400 DEBUG otopi.plugins.otopi.packagers.yumpackager yum packager.verbose:76 Yum Done: ovirt-vmconsole-1.0.4-1.el7.centos.noarch 2019-10-27 10:42:18,605-0400 DEBUG otopi.plugins.otopi.packagers.yumpackager yum packager.verbose:76 Yum Script sink: D: --- h# 747 ovirt-vmconsole-1.0.4-1 .el7.centos.noarch

This appears to be https://bugzilla.redhat.com/show_bug.cgi?id=1665197 which is closed as being fixed in 4.3.1, but that *STILL* doesn't help when trying to upgrade the engine from 4.1. to 4.2. It should have been fixed for 4.2.8 (or push a 4.2.9 with the fix).

I admit I don't remember the details anymore (I was involved but didn't fix your bug myself, nor managed to reproduce), but I think that a fix in 4.2.Z wouldn't have helped you, because the bug happened in the %postun snippet of the previous version, in your case 4.1. At the time, I think we didn't manage to come up with a fix for the upgrade itself at all, only for future upgrades (from a fixed version), other than fixing the above otopi bug (which we decided not to fix).

After googling around, I was able to work around this bug by moving semodule out of the way:

mv /usr/sbin/semodule{,-bak} ln -fs /bin/true /usr/sbin/semodule

and then running the update (I reverted after the update). I don't *like* this solution, but it got it working.

Did you try the workaround suggested in your bug, comment 5? Which is to upgrade ovirt-vmconsole yourself using yum? It should still have emitted an error, but yum indeed considers it non-fatal, and you are then free to agree with it (unlike in otopi). BTW, I do not object to "fixing" the otopi bug *optionally* - to make it keep its current behavior by default, but allow setting some conf to make it ignore such errors. The standard comment about the price of adding more options etc., obviously applies... https://xkcd.com/1172/ Would you want such an option? Not sure it would have helped you much. Finding it, assuming it existed, would probably not be easier than finding the workaround (either the one you tried or upgrading manually).

I'll note that I have SELinux set to "enforcing", and I started with EL7.2/OV4.0 and have upgraded a few times.

Thanks a lot for the report! Best regards, -- Didi