[Bug 1714090] Re: grub2 upgrade doesn't preserve current boot order.

[Rod Smith]

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
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1714090

Title:
  grub2 upgrade doesn't preserve current boot order.

Status in grub2 package in Ubuntu:
  New

Bug description:
  This is a follow up discussion from #1642298 and filing this bug to
  keep a record.

  On a fresh Ubuntu install, grub2 overwrites the NVRAM and updates to
  boot order to have Ubuntu as the first boot device. This affects
  situations in which PXE had been set the first boot device in the boot
  order as it would overwrite it.

  However, every single time grub2 package upgrades, it will overwrite
  the NVRAM and completely override the boot order again. For example,
  consider that ubuntu is first in the boot order.

  efibootmgr -v
  BootCurrent: 0000
  Timeout: 2 seconds
  BootOrder: 0000,0001
  Boot0000* ubuntu
  Boot0001  PCI LAN

  But the administrator changed Network to be the first in the boot
  order.

  efibootmgr -v
  BootCurrent: 0001
  Timeout: 2 seconds
  BootOrder: 0001,0000
  Boot0001* PCI LAN
  Boot0000  ubuntu

  After a package upgrade, grub will overwrite the NVRAM and change this
  back to:

  
  efibootmgr -v
  BootCurrent: 0000
  Timeout: 2 seconds
  BootOrder: 0000,0001
  Boot0000* ubuntu
  Boot0001  PCI LAN

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1714090/+subscriptions