Comment 18 for bug 1834190

Bug #1846355 was marked as a duplicate of this one, but it seems the cloud image's initial boot is still quite long in groovy. I see that performance has greatly improved in groovy, but snapd still accounts for almost half of the time spent in the initial first boot.

snap.seeded has the top spot of systemd-analyze blame for this first boot using the same script as in bug #1846355:

2min 10.521s snapd.seeded.service
     45.134s snapd.apparmor.service
     38.917s cloud-init.service
     37.197s dev-vda1.device
     36.135s cloud-config.service
     32.090s cloud-init-local.service
     27.304s snapd.service
     26.047s systemd-udev-settle.service
     24.403s apparmor.service
     22.987s cloud-final.service
     21.231s accounts-daemon.service
     20.568s pollinate.service
     17.044s snap.lxd.activate.service
     16.678s networkd-dispatcher.service
     11.466s systemd-udev-trigger.service
     11.386s apport.service
      9.659s systemd-logind.service
      9.568s grub-common.service
      8.293s keyboard-setup.service
      5.803s systemd-journald.service
      4.975s grub-initrd-fallback.service
      4.908s rsyslog.service
      4.742s user@1000.service
      4.481s blk-availability.service
      4.280s atd.service
      4.033s systemd-resolved.service
      3.656s systemd-timesyncd.service

(note that it's twice as fast as before)