http://bugzilla.opensuse.org/show_bug.cgi?id=1193426 http://bugzilla.opensuse.org/show_bug.cgi?id=1193426#c1 --- Comment #1 from Christian Boltz --- Interesting[tm]. There weren't any recent changes in AppArmor which would easily explain this message, and I don't have an "easy answer" that could explain why you see this message now (and not before). Do you have an idea if there were other (seemingly unrelated) changes that could cause this? For example kernel or systemd changes that could result in mounting (or remounting rw) /var/ later, or running apparmor.service earlier? BTW: Compared with the previous build https://openqa.opensuse.org/tests/2066258#step/journal_check/8 there are *lots of* new error messages (mostly around dma). I'm not sure if they are related, but they are also worth investigating (probably by the kernel team). -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1193426 Bj�rn Voigt changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bjoernv@arcor.de -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1193426 http://bugzilla.opensuse.org/show_bug.cgi?id=1193426#c6 Christian Boltz changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(suse-beta@cboltz. | |de) | --- Comment #6 from Christian Boltz --- Sorry for the delay, this somehow fell off my radar :-( The fact that AppArmor wasn't installed before explains why you didn't see this message before ;-) Jokes aside - IMHO this sounds like a race condition or too early start of apparmor.service - while /var/cache/ is still mounted read-only, and not re-mounted rw yet. (To confirm this theory, can you test with "rw" in the kernel command line?) Seeing the systemd-analyze plot result might also give some insight and hints. (On my laptop, apparmor.service starts some ms after systemd-remount-fs.service which seems to be enough. Maybe that's different on the Pi and/or the remount takes longer?) Note: apparmor.service already has After=var.mount var-cache.mount usr.mount usr-share.mount but I don't know if that means "somehow (= ro) mounted" or "mounted rw". Maybe you can try adding After=systemd-remount-fs.service to apparmor.service to find out and possibly solve this bug. (If you do this, please check systemd-analyze plot to ensure it doesn't add too much delay. The goal is to load the AppArmor profiles as early as possible.) BTW: The message isn't too harmful - in worst case, it makes the next boot a bit slower if the cache can't be written. AppArmor will still work even without the cache. -- You are receiving this mail because: You are on the CC list for the bug.