Comment 4 for bug 1423372

Update: due to some (recent) changes in the maas provider in trunk switching to the debian (slow) installer causes the bootstrap to fail with:
...
2015-02-19 17:07:52 DEBUG juju.environs cloudinit.go:171 Setting numa ctl preference to false
2015-02-19 17:07:52 DEBUG juju.provider.maas environ.go:931 maas user data; 1222 bytes
2015-02-19 17:07:53 DEBUG juju.provider.maas environ.go:936 started instance "/MAAS/api/1.0/nodes/node-fc3bdec0-c163-11e3-84a7-525400355a63/"
2015-02-19 17:07:53 DEBUG juju.provider.common state.go:36 putting "provider-state" to bootstrap storage *maas.maasStorage
 - /MAAS/api/1.0/nodes/node-fc3bdec0-c163-11e3-84a7-525400355a63/
2015-02-19 17:11:58 ERROR juju.cmd supercommand.go:411 failed to bootstrap environment: bootstrap instance started but did not change to Deployed state: instance "/MAAS/api/1.0/nodes/node-fc3bdec0-c163-11e3-84a7-525400355a63/" is started but not deployed

That's despite having "bootstrap-timeout: 1200" [s] in my environments.yaml. But that's another story.

Some minutes after juju gave up, the node finished installing and I can confirm after SSH-ing in and running "apt-cache policy biosdevname" that it's installed (unlike before). But the network interfaces everywhere are still called ethX rather than emX as I expected. This is juju 1.23-alpha1-trusty-amd64 and maas 1.8-alpha from rvba's ppa.