I've tried adding Ryan Harper's suggested workaround[1] to the MAAS curtin preseed file (/etc/maas/preseeds/curtin), to no effect; the node (I was using drapion for testing) still deploys with the system set to boot from hard disk (via the "ubuntu" entry in the EFI boot order). I also tried putting those lines in /etc/maas/preseeds/curtin_userdata, which we modify in our certification MAAS server for other purposes. (We do not create a "grub" entry by default, so there's no conflict over this detail.)
Please review my comments in posts #29 and #30, above. The affected servers don't produce a BootCurrent variable under some circumstances, which seems to be throwing off the algorithms that curtin uses. This is almost certainly a bug in some firmware implementations, but getting multiple vendors to fix their firmware is a nightmare, so if a workaround in curtin or MAAS is possible, such a workaround should be pursued.
I've tried adding Ryan Harper's suggested workaround[1] to the MAAS curtin preseed file (/etc/maas/ preseeds/ curtin) , to no effect; the node (I was using drapion for testing) still deploys with the system set to boot from hard disk (via the "ubuntu" entry in the EFI boot order). I also tried putting those lines in /etc/maas/ preseeds/ curtin_ userdata, which we modify in our certification MAAS server for other purposes. (We do not create a "grub" entry by default, so there's no conflict over this detail.)
Please review my comments in posts #29 and #30, above. The affected servers don't produce a BootCurrent variable under some circumstances, which seems to be throwing off the algorithms that curtin uses. This is almost certainly a bug in some firmware implementations, but getting multiple vendors to fix their firmware is a nightmare, so if a workaround in curtin or MAAS is possible, such a workaround should be pursued.
grub:
reorder_uefi: false