Hi, On Mon, Oct 28, 2019 at 3:04 PM Derek Atkins <[email protected]> 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 _______________________________________________ Users mailing list -- [email protected] To unsubscribe send an email to [email protected] Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/[email protected]/message/ALAMPFKXRKZ7QT67NDXKKMUQ72C3XXMW/
