problem loading new apparmor profiles because timestamps were in the future

[Han Boetes]

TLDR; make sure the time is properly configured or at least in the past before proceeding with the install. Probably this is what the installer itself should do.

I noticed my apparmor profiles weren't loading on one of the 2 new, identical machines I set up.

After lots of head scratching I noticed this:

root@ernie /var/cache/apparmor/7f01cf2e.0 # l
total 192K
drwx------ 2 root root 10 Feb 12 10:14 .
drwxr-xr-x 3 root root 3 Dec 12 2020 ..
-rw-r--r-- 1 root root 1.5K Dec 12 2020 .features
-rw------- 1 root root 122K Dec 12 2020 lxc-containers
-rw------- 1 root root 35K Dec 12 2020 nvidia_modprobe
-rw------- 1 root root 34K Dec 12 2020 usr.bin.man
-rw------- 1 root root 31K Dec 12 2020 usr.sbin.chronyd
-rw------- 1 root root 34K Dec 12 2020 usr.sbin.ntpd
-rw------- 1 root root 49K Dec 12 2020 usr.sbin.tcpdump
-rw------- 1 root root 8.1K Dec 12 2020 usr.bin.lxc-start

Yes, that's right, the date is off, it's 10 month ahead of time. So I removed the directory and ran systemctl force-reload apparmor, only to find the generated files had exactly the same timestamp. With locate I found the origins of those files in /etc/ and noticed a lot of files with the wrong timestamps. So I ran(yes, rather brutal):

find /etc -exec touch -h '{}' \;

And things started working again.

 

[Stoiko Ivanov]

Thanks for sharing the information! could you maybe also post the log-messages which brought you to the issue?
(This would help other users who search for the log messages)

Thanks!

 

[Han Boetes]

I can't remember nor reproduce the exact error messages, but basically the new apparmor lxc profiles were not loaded after running systemctl reload apparmor.service which you will also find in the dmesg and if you run lxc-start -F 123 even though the apparmor config files are identical to the ones on other systems and reloading apparmor goes without error.