Hello, Am Mittwoch, 16. November 2022, 18:24:06 CET schrieb Joe Salmeri:
Submitted upstream: https://gitlab.com/apparmor/apparmor/-/merge_requests/948
Thanks very much.
This entire situation got me thinking. Seems like there should be some sort of --force option with apparmor to have it force an update of the cache to avoid the problem in the future. Then that could be used whenever apparmor is updated in a new build.
Does anything like that exist?
apparmor_parser --skip-read-cache --write-cache -r /etc/apparmor.d/ should do that. ("Should" because I didn't test it - but the manpage explicitely recommends this combination.) An easier-to-remember way is to touch /etc/apparmor.d/$whatever which will also rebuild the cache for profiles including this file when the profiles get reloaded next time. That said - not shipping the precompiled cache is the easiest way to avoid problems like yours. I changed the package so that it doesn't include the precompiled cache for Tumbleweed anymore (SR was accepted yesterday, will be included in one of the next Tumbleweed snapshots). The only disadvantage is that booting after a major kernel update (with a new AppArmor feature hash) will need some additional seconds to build a new cache. (Updates of the apparmor-profiles or apparmor-abstractions package will also build a new cache, but that gets done after package installation.) For a more detailed (and summarized) description, see boo#1205659 Regards, Christian Boltz -- <suseROCKs> mrdocs, this is California. Define "normal" [from #opensuse-project]