Comment 5 for bug 1311827

I've just double-checked, and it does the same thing in the fastpath install as in the d-i install.

This is not a problem when doing a conventional (non-MAAS) install because it's the way EFI/UEFI is supposed to work; the OS registers its (on-disk) boot loader with the firmware, which then launches the boot loader based on its own built-in boot manager's rules. The problem is that this EFI convention doesn't work well with MAAS, or at least MAAS should modify it so that the MAAS server can retain control of its nodes' boot processes. As it stands now, MAAS is unable to re-start an EFI-booting node once it's been stopped unless somebody takes manual steps (to delete GRUB or to modify the boot order).

I don't know the details of the various scripts involved in the various installers, but from my perspective, the simplest way to prevent this problem from occurring is to have the installers NOT call efibootmgr to register GRUB with the firmware. This might require changes to MAAS scripts and/or to the GRUB installation scripts. It's conceivable that something else (system update tools, for instance) might also call efibootmgr to re-register GRUB, so inquiries should be made about that.

If the GRUB scripts automatically set it up, and if the GRUB package maintainers are unwilling to change it, then the second-best option is to have MAAS remove the GRUB entries from the NVRAM, or at least change the BootOrder variable to omit GRUB. This will entail parsing the efibootmgr output to identify GRUB so that its entry can be removed or omitted from BootOrder.