Comment 1 for bug 1460152

<jdstrand> rsalveti: I'm only putting this out there as an option that you are free to ignore-- there are only 3 system profiles on core. pregenerated them doesn't buy us much on first boot-- about 2.2 seconds on bbb
<jdstrand> rsalveti: maybe on upgrade hook could simply rm -f /etc/apparmor.d/cache/*
<jdstrand> rsalveti: could the a/b partitioning be getting in the way?
<jdstrand> rsalveti: ie, are the writable bind mounted areas a/b'd as well?
<rsalveti> that's an interesting question
* ogra_ thought not
<ogra_> we only have one writable and a and b
<jdstrand> rsalveti: eg, if a has old cache and old profile and we reboot into b with new profile, do we get a's old cache file?
<rsalveti> yeah, are we sharing the same writable path for the cache?
<rsalveti> if so, then, hmm
<ogra_> most likely
<rsalveti> not good
<ogra_> since we only have one writable partition
<rsalveti> ogra_: can you confirm?
<ogra_> yeah, i think i can
<ogra_> three partitions ... two readonly, one writable ...
<ogra_> writable gets mounted in initrd by label, no matter what readonly part is active
<ogra_> and /etc/apparmor.d/cache is in /etc/system-image/writable-paths
<ogra_> i guess we would want an a/b scheme there
<ogra_> in a subdir or some such
<ogra_> or via a bind mount that hides the real path
<jdstrand> ok, so I'm much more convinced that for now, we rm -f /etc/apparmor.d/cache/*
<jdstrand> cause the alternative would be too risky for sru
<jdstrand> we need to implement the alternative for touch anyway
<jdstrand> s/touch/personal/
<rsalveti> ogra_: jdstrand: yeah, let's just do this
<rsalveti> sharing same writable path can be indeed dangerous
<rsalveti> it's usually desirable
<rsalveti> but we need to be careful