Comment 10 for bug 1575572

> This behaviour of installing packages or configuring your system while the
> system isn't booted yet might also bite you in other cases (it certainly bit
> me a number of cases). Maybe we should discuss how to move that after the
> boot? I do that in
> https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/tools/armf-lxd-slave.userdata
> but this doesn't look very pretty.

The goal of cloud-init is basically to allow the user to do whatever they could have done by creating their own image. But instead, do that via feeding data to the system.

The portion of cloud-init that installs packages for a user can be moved to a later stage, but can't really be moved *out* of boot.

sysvinit and upstart support this functionality well. upstart *really* does the right thing in that you can add new jobs and when conditions are met those jobs will be handled.

Also note that "in the boot sequence" is not really the problem. The problem is that the package installation is happening before the system is completely booted. As an example of the difference, consider that any hung or blocked systemd service will break installation of services. I can show this by:
 a.) new xenial container
 b.) modify /etc/rc.local to have 'sleep 5m'
 c.) start container
 d.) lxc exec name apt-get install apache2
 e.) apt-get install apache2

The same problem can be shown with 'd' being invoked via ssh, or *any* other mechanism on the system.