[Group.of.nepali.translators] [Bug 1642298] Re: UEFI Xenial install sets computer to boot from hard disk

[Mike Pontillo]

Targeting for MAAS 2.3.0 since it sounds like MAAS changes are required.

** Changed in: maas
   Status: Invalid => Triaged

** Changed in: maas
   Importance: Undecided => High

** Changed in: maas
Milestone: None => 2.3.0

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1642298

Title:
  UEFI Xenial install sets computer to boot from hard disk

Status in curtin:
  Confirmed
Status in MAAS:
  Triaged
Status in grub2 package in Ubuntu:
  Fix Released
Status in grub2 source package in Trusty:
  Triaged
Status in grub2 source package in Xenial:
  Triaged
Status in grub2 source package in Yakkety:
  Triaged

Bug description:
  [Impact]
  Typically when you install Ubuntu on an EFI system, it installs a new default 
EFI boot entry that makes the system reboot directly into the OS. During MAAS 
installs, curtin is careful to disable that behavior. MAAS requires the default 
boot entry to remain PXE, so that it can direct the system to boot from disk or 
network as necessary. curtin does this by passing --no-nvram to grub-install 
when installing the bootloader.

  *Update*: newer curtin releases actually allow the creation of a new
  boot entry, but updates the boot menu to make PXE the default. That
  change is orthogonal to this bug.

  ***However***, this doesn't stop a new default boot entry from being
  added after deploy. If the user installs a grub package update or
  manually runs 'grub-install', booting from disk will become the
  default, and MAAS will lose control of the system.

  [Proposed Solution (er... glorified workaround)]
  The GRUB package in zesty now has support for setting the --no-nvram flag 
*persistently*. This is implemented via a debconf template 
(grub2/update_nvram). If curtin sets this flag to "false" during install, 
post-deploy grub updates will also pass the --no-nvram flag when running 
grub-install.

  This isn't a perfect solution - users can still call grub-install
  manually and omit this flag.

  [Test Case]
   - MAAS deploy an EFI system.
   - After deploy, login and run 'sudo apt --reinstall install grub-efi-$(dpkg 
--print-architecture)
   - Reboot and observe that the system does not PXE boot.

  [Regression Risk]
   - The GRUB implementation does not change the defaults of the package. The 
user would need to opt-in to the "grub2/update_nvram=false". This option is 
also only presented to users who specifically request a low debconf priority 
(e.g. expert mode installs).
   - XXX curtin risk XXX

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1642298] Re: UEFI Xenial install sets computer to boot from hard disk

[dann frazier]

The grub2 changes are in zesty as of 2.02~beta3-4ubuntu1. Could I ask
the curtin developers to take a look at implementing the necessary
changes there? Specifically, using the new grub2/update_nvram preseed
instead of manually passing --no-nvram to grub-install during install.

** Also affects: grub2 (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Also affects: grub2 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: grub2 (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Changed in: grub2 (Ubuntu)
   Status: Confirmed => Fix Released

** Changed in: grub2 (Ubuntu Trusty)
   Status: New => Triaged

** Changed in: grub2 (Ubuntu Yakkety)
   Status: New => Triaged

** Changed in: grub2 (Ubuntu Xenial)
   Status: New => Triaged

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1642298

Title:
  UEFI Xenial install sets computer to boot from hard disk

Status in curtin:
  Confirmed
Status in MAAS:
  Invalid
Status in grub2 package in Ubuntu:
  Fix Released
Status in grub2 source package in Trusty:
  Triaged
Status in grub2 source package in Xenial:
  Triaged
Status in grub2 source package in Yakkety:
  Triaged

Bug description:
  This bug is a regression of bug #1311827.

  On a current MAAS 2.0 installation, I've discovered that MAAS is now
  overriding the PXE-boot settings, causing the system to attempt to
  boot directly from the grubx64.efi on the hard disk's EFI System
  Partition (ESP). After installation, the result looks like this:

  ubuntu@oil-hatanaka:~$ sudo efibootmgr
  BootCurrent: 0005
  Timeout: 1 seconds
  BootOrder: 0005,0001,0002,0003,0004
  Boot0001* UEFI: IP4 ELX NIC Bus:Dev:Func 3:0:0 - Fujitsu DynamicLoM Emulex 
OCl14000-LOM
  Boot0002* UEFI: IP6 ELX NIC Bus:Dev:Func 3:0:0 - Fujitsu DynamicLoM Emulex 
OCl14000-LOM
  Boot0003* UEFI: IP4 ELX NIC Bus:Dev:Func 3:0:1 - Fujitsu DynamicLoM Emulex 
OCl14000-LOM
  Boot0004* UEFI: IP6 ELX NIC Bus:Dev:Func 3:0:1 - Fujitsu DynamicLoM Emulex 
OCl14000-LOM
  Boot0005* ubuntu

  Note that BootOrder specifies Boot0005 as the first option, causing
  the computer to attempt to boot from the hard disk rather than PXE-
  boot (any of the other Boot options on this computer). This causes
  at least two problems:

  * If Secure Boot is enabled, the computer may fail to boot, because the 
"ubuntu" entry points
to grubx64.efi, not shimx64.efi. (If the computer silently falls past the 
SB failure, it
will boot; but on the Fujitsu system I tested, it displays a console 
message about the SB
failure that requires human interaction, and therefore hangs indefinitely 
in a MAAS
environment.)
  * Re-deploying the node is impossible without manual intervention, because 
the system
will try to boot from the hard disk rather than PXE-booting under MAAS 
control.

  This problem has occurred on a server running MAAS
  2.0.0+bzr5189-0ubuntu1~16.04.1 (see below for detailed version
  information). Another server running MAAS
  2.1.0+bzr5480-0ubuntu1~16.04.1 does NOT have the problem. I suspect
  the problem is with the ephemeral images, though, not the MAAS version
  per se. I'm attaching the log files from the MAAS 2.0 system as
  requested.

  I've tested this with three systems: A Fujitsu RX2530M2R2, a Fujitsu
  RX2540M2R1, and an IBM x3650 M2. (The MAAS 2.1 server controlled an
  Intel NUC DC53427HYE.) The Fujitsu systems are new (to us), but the
  IBM has been in our possession for an extended period and has never
  exhibited this problem (except perhaps when bug #1311827 was current),
  so I'm confident this is a regression.

  All tests involved deployments of Ubuntu 16.04. Most used the
  certification custom images (for 16.04.1), but I've verified the
  results on one system deploying the standard MAAS image for xenial.

  MAAS version information:

  rodsmith@weavile:~$ dpkg -l '*maas*'|cat
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ NameVersion
Architecture Description
  
+++-===-==--==
  ii  maas2.0.0+bzr5189-0ubuntu1~16.04.1 all
  "Metal as a Service" is a physical cloud and IPAM
  ii  maas-cert-server0.2.25-0~64~ubuntu16.04.1  all
  Ubuntu certification support files for MAAS server
  ii  maas-cli2.0.0+bzr5189-0ubuntu1~16.04.1 all
  MAAS client and command-line interface
  un  maas-cluster-controller   
  (no description available)
  ii  maas-common