Comment # 2 on bug 1069906 from
This is... interesting ;-)

John already explained the reason for the errors. Let me add that running
"rcapparmor reload" in the running system (when /var/lib/apparmor/ is
writeable) will also update the cache.


There are more interesting things: apparmor.service has
    After=var.mount var-lib.mount
so I'd expect it to start late enough.
(Note that apparmor.service should start as early as possible - the profiles
have to be loaded before the programs they confine start.)


I also wonder about a few lines in your log, especially

Nov 27 10:11:02 localhost systemd[1]: var-lib-overlay.mount: Unit is bound to
inactive unit dev-vda2.device. Stopping, too.
Nov 27 10:11:02 localhost systemd[1]: Requested transaction contradicts
existing jobs: Transaction is destructive.
Nov 27 10:11:02 localhost systemd[1]: var-lib-overlay.mount: Failed to enqueue
stop job, ignoring: Transaction is destructive.

I don't know what these messages mean exactly, but (assuming/guessing that they
refer to an overlay mount for /var/lib/) they could be a part of the puzzle.


I never tried Kubic or Caas, therefore I can only guess what happens, and hope
that the above hints help you to understand the problem. If you have an idea
how to handle this (ideally without delaying loading the profiles), please tell
me ;-)


You are receiving this mail because: