Steve, there have been two problems that are feeding into this bug report, both on MAAS installations to EFI-based nodes, which must normally PXE-boot so that the MAAS server can maintain control of its nodes:
* After GRUB package updates, the GRUB package would add GRUB to the start of the boot order, thus removing MAAS's ability to control the node. (MAAS had been preventing the GRUB package from setting the boot order during the initial installation, but MAAS loses control of this detail when software is subsequently updated.) This would sometimes happen immediately after an installation, but other times it would take weeks or months before a new GRUB package would become available. Dann Frazier produced a patch to fix this, as noted in bug #1642298 (although I don't think his fix is actually linked to that bug report). Dann's fix worked by setting a debconf variable to prevent GRUB updates from making changes to the boot order. * After Dann's fix was in place, it was noted that, because there was no GRUB entry in the boot order, if the MAAS server became inaccessible, nodes would become unbootable. I believe a bug was filed for this, but I don't happen to have a reference. In fixing this second bug, changes were made that caused a regression on bug #1642298, as noted in comments #21, #23, and later to that bug report. I don't see a way to address the second issue without re-ordering the NVRAM-based boot order -- AFAIK, efibootmgr always adds a new entry as the first item, so either you'll have no GRUB entry (as in Dann's initial fix to bug #1642298), but this will leave the second issue unaddressed; or you'll have to change the order of boot entries created when the GRUB package creates a GRUB entry as the first one in NVRAM. Of course, leaving that second problem (nodes not booting if the MAAS server becomes inaccessible) unaddressed is another option -- although perhaps not to whoever encountered it. Note also that when I say "GRUB entry," the entry may actually point to shimx64.efi. I don't think I've looked into what ITS packaging does; there might or might not be a parallel problem there. Dann traced the initial problem to the GRUB package, and that's where his fix was applied. This all "just works" on conventional BIOS-based systems because they've got a much simpler boot configuration that isn't changed from the node itself, but that can be changed by MAAS, at least on servers that use IPMI. (Those IPMI features don't work on EFI-based computers, so they aren't helpful in resolving this problem, which applies only to EFI- based computers.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1714090 Title: grub2 upgrade doesn't preserve current boot order. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1714090/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
