Comment 14 for bug 1604962

Currently, the problem I believe that we're seeing is due to the way in which curtin implements its reboot.
Basically, when curtin is done with install, it backgrounds a processes that does:
   sleep 5
   reboot

As I understand this problem, the race condition is that the 'reboot' is happening before cloud-init is finished. reboot tells systemd to kill all processes and shutdown. systemd kills cloud-init, cloud-init exits (and reports) failure because it is not done.

If that is the case, then the situtation can be avoided simply by adding a longer 'delay' to the curtin configuration that maas sends.

In /etc/maas/preseeds/curtin_userdata, there is a section here that looks like:
  power_state:
    mode: reboot

You can change this to say:
  power_state:
    mode: reboot
    delay: 30