2:03 a.m.
Hi,
On Mon, Oct 28, 2019 at 3:04 PM Derek Atkins <derek(a)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