I've heard that even cloud images that were shipping snaps before the LXD inclusion are seeing a ~10s slowdown. If that's indeed the case, can we get a before/after for those with:
- systemd-analyze critical-chain - journalctl --boot 0 - ps fauxww The LXD snap at boot time should be spending less than a second running "snap.lxd.activate" (equivalent to "lxd-containers" pre-snap) at which point it should decide not to wake the daemon and move on with startup without spending any more time doing LXD related things. So it could be that something's wrong in "lxd.activate" similar to what I fixed on Friday or snapd is somehow spending a lot of time mounting stuff at boot time or we've sufficiently reshuffled the systemd boot sequence to cause a massive delay somewhere? I think we should be focusing on this right now, before we look into images that didn't use to have any snaps inside them before. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1796137 Title: huge and slow image 20181002 due to seeded lxd snap To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1796137/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
