All that said, Daniel and Jean-Baptiste, I installed 20.04 in a vm and tried to reproduce this and could not. The apparmor change was about correctness of the unit so I performed the upload, but I also hoped that it would address the issue you are seeing.
I'm not certain it will. On one boot, prior to upgrading apparmor, I saw: $ sudo systemd-analyze critical-chain apparmor.service The time when unit became active or started is printed after the "@" character. The time the unit took to start is printed after the "+" character. apparmor.service +11.135s └─local-fs.target @4.376s └─zfs-mount.service @4.327s +48ms └─var-lib-dpkg.mount @4.188s +137ms └─var-lib.mount @3.883s +250ms └─zfs-import.target @3.829s └─zfs-import-cache.service @3.125s +704ms └─zfs-load-module.service @3.121s +2ms └─systemd-udev-settle.service @1.183s +1.937s └─systemd-udev-trigger.service @933ms +248ms └─systemd-udevd-kernel.socket @886ms └─system.slice @535ms └─-.slice @535ms Note that var-lib.mount is already listed. On reboot though (without updating apparmor), I see: $ sudo systemd-analyze critical-chain apparmor.service The time when unit became active or started is printed after the "@" character. The time the unit took to start is printed after the "+" character. apparmor.service +101ms └─local-fs.target @2.812s └─run-user-122.mount @5.172s └─swap.target @1.823s └─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.swap @1.799s +22ms └─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.device @1.798s Oddly, no zfs entries are listed apparently because local-fs.target isn't pulling them in: $ sudo systemd-analyze critical-chain local-fs.target The time when unit became active or started is printed after the "@" character. The time the unit took to start is printed after the "+" character. local-fs.target @2.812s └─run-user-122.mount @5.172s └─swap.target @1.823s └─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.swap @1.799s +22ms └─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.device @1.798s Looking at var-lib.mount, I see zfs is in there: $ sudo systemd-analyze critical-chain var-lib.mount The time when unit became active or started is printed after the "@" character. The time the unit took to start is printed after the "+" character. var-lib.mount +179ms └─zfs-import.target @2.248s └─zfs-import-cache.service @1.845s +402ms └─zfs-load-module.service @1.840s +2ms └─systemd-udev-settle.service @692ms +1.143s └─systemd-udev-trigger.service @524ms +167ms └─systemd-udevd-kernel.socket @494ms └─system.slice @357ms └─-.slice @357ms So why after a reboot did the dependencies change and drop the /var/lib entry from local-fs.target? I then upgraded apparmor to have the RequiresMountsFor /var/lib/snapd/apparmor/profiles, rebooted and saw no difference: $ sudo systemd-analyze critical-chain apparmor.service The time when unit became active or started is printed after the "@" character. The time the unit took to start is printed after the "+" character. apparmor.service +222ms └─local-fs.target @2.562s └─run-user-122.mount @4.834s └─swap.target @1.687s └─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.swap @1.663s +24ms └─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.device @1.662s ** Changed in: zsys (Ubuntu Focal) Status: Invalid => New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1871148 Title: services start before apparmor profiles are loaded To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1871148/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs