Comment 4 for bug 1473167

It's likely that you see it boot back into the enlistment environment because it's simply still on disk from a previous enlistment.

In particular, since you're testing with KVM virtual machines, during 1.8 development we made the decision to set the boot order to [network, local_disk] in the virtual BIOS (KVM virtual machine settings, in this case).

Since every BIOS behaves differently (virtual or non-virtual), this issue may manifest itself similarly (or very differently) on other types of systems.

At the time, I asked if we wanted to recommend, require, or enforce that MAAS managed machines *only* PXE boot after they become managed nodes. And we decided that the safest bet was to set them to fall back to a local disk, because we didn't want deployed nodes to fail to boot due to the MAAS DHCP server being unavailable. (but clearly, there are other corner cases where this fallback cannot happen - and yet more corner cases where we have very little control over the boot order.)

So, in no particular order, I think the possible fixes are:

(1) Check whether we have the boot image the user is requesting before trying to boot
(2) Enforce boot order in a more refined manner (such as, when managing virtual machines, only include local disks after the machine has been deployed. *However*, we may not always have such fine-grained control.)

You might also try replacing "releases" with "daily" in your boot images path; there may be additional unreleased images you can try. (though I haven't checked if that's true for this particular case; Scott probably knows better.)