I read into an mysql dh_apparmor case (bug 1435368) that was mentioned
that it might be related.
There as well a postinst call has issues due to not yet reloaded
apparmor profiles.
But the libvirt postinst already has:
for p in usr.sbin.libvirtd usr.lib.libvirt.virt-aa-helper ; do
profile="/etc/apparmor.d/$p"
if [ -f "$profile" ] && aa-status --enabled 2>/dev/null; then
apparmor_parser -r "$profile" || true
fi
done
While that lacks the --remove and the --purge-cache of the workaround it should
still update the profile.
Yet there is a '|| true', so one might have failed to reload and then trigger.
Also the libvirt postinst seems to intentionally carry all restarting code
AFTER the #DEBHELPER# section.
So the dh_apparmor code would run there I think and later code in the postinst
should only face the reloaded profiles.
I wonder how/where/which-log could confirmed that these reloads (the explicit
one from postinst and the apparmor one) failed ...? The service is restarted
automatically
Maybe if one can reproduce the case he could debug that.
So please:
1. if one can modify my steps-to-repro in a way that they trigger please let us
know
2. If one runs into this, before applying the workaround please check which
profiles are loaded.
Unfortunately I don't know a good way to check if the loaded one (assumed to
be old) matches the on disk profile (new after update).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1594902
Title:
Failed to upgrade to libvirt-bin 1.3.1-1ubuntu10.1 on Ubuntu 16.04
64-bit
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1594902/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
