[Bug 1750732] Re: grub package will change the boot order for MaaS deployed system

[dann frazier]

The system was set to boot from PXE by default, at least before MAAS deployed it:
Feb 22 03:28:41 lodygin cloud-init[3447]: + echo before grub-install efiboot settings
Feb 22 03:28:41 lodygin cloud-init[3447]: before grub-install efiboot settings
Feb 22 03:28:41 lodygin cloud-init[3447]: + efibootmgr
Feb 22 03:28:41 lodygin cloud-init[3447]: BootCurrent: 0002
Feb 22 03:28:41 lodygin cloud-init[3447]: Timeout: 1 seconds
Feb 22 03:28:41 lodygin cloud-init[3447]: BootOrder: 0002,0003,0004
Feb 22 03:28:41 lodygin cloud-init[3447]: Boot0002* UEFI: IP4 Intel(R) Gigabit CT Desktop Adapter
Feb 22 03:28:41 lodygin cloud-init[3447]: Boot0003* UEFI: Built-in EFI Shell
Feb 22 03:28:41 lodygin cloud-init[3447]: Boot0004* Hard Drive

Now, curtin will install an entry and monkey with the boot order during
deployment. I'm aware of a couple of firmware implementations where that
breaks things - but I don't see signs of those known issues here. And,
after deploy you say efibootmgr output looks correct - so that suggests
nothing has gone wrong yet.

As @cyphermox mentioned, maas/curtin should be configuring the system to
skip modifying NVRAM. And the debconf-get-selections output confirms
this:

# Update NVRAM variables to automatically boot into Debian?
grub-efi-amd64	grub2/update_nvram	boolean	false
grub-pc	grub2/update_nvram	boolean	false
grub2	grub2/update_nvram	boolean	false

This means efibootmgr output *should be* the same before and after you
upgrade GRUB. Can you confirm that is true? Since you mention rebooting
as step #4 in reproduction - that suggests the boot order breakage is
occuring somewhere in firmware after reboot.

Regarding @cyphermox's point about shim fallback.... these days, curtin
leaves the system with an Ubuntu entry, but makes it the 2nd option in
the bootorder. The idea is that if MAAS is down for some reason, the
system will fallback to booting from the disk (instead of failing to
boot altogether). What would happen if PXE failed, and Ubuntu - as the
2nd priority boot option - started? Would shim fallback reorder the
menu?

-- 
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/1750732

Title:
  grub package will change the boot order for MaaS deployed system

Status in curtin package in Ubuntu:
  New
Status in grub2 package in Ubuntu:
  Incomplete
Status in maas package in Ubuntu:
  New

Bug description:
  Similar to bug 1642298, this issue strikes back (looks like it's only
  affecting our node "lodygin - AMD Speedway Naples 2U" in the test
  pool)

  Steps:
   1. Deploy a system with Xenial
   2. Check the boot order with `efibootmgr`
   3. Upgrade grub-efi-amd64 from proposed
   4. Reboot
   5. Check the `efibootmgr` again

  Result:
   * The boot order will be overrided to boot from disk first, MaaS needs it to boot with PXE first.

  Package version:
  grub-common   2.02~beta2-36ubuntu3.17
  grub-efi-amd64   2.02~beta2-36ubuntu3.17
  grub-efi-amd64-bin   2.02~beta2-36ubuntu3.17
  grub-efi-amd64-signed   1.66.17+2.02~beta2-36ubuntu3.17
  grub-pc   2.02~beta2-36ubuntu3.16
  grub-pc-bin   2.02~beta2-36ubuntu3.17
  grub2-common   2.02~beta2-36ubuntu3.17

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: grub-efi-amd64 2.02~beta2-36ubuntu3.17
  ProcVersionSignature: User Name 4.4.0-112.135-generic 4.4.98
  Uname: Linux 4.4.0-112-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.15
  Architecture: amd64
  Date: Wed Feb 21 06:09:29 2018
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=<set>
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: grub2
  UpgradeStatus: No upgrade log present (probably fresh install)

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