[Bug 1642298] Re: UEFI Xenial install sets computer to boot from hard disk
dann frazier
dann.frazier at canonical.com
Fri Feb 10 18:31:30 UTC 2017
** Description changed:
- This bug is a regression of bug #1311827.
+ [Impact]
+ Typically when you install Ubuntu on an EFI system, it installs a new default EFI boot entry that makes the system boot 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.
- 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:
+ ***However***, this doesn't stop a boot entry from being added after
+ deploy. If the user installs a grub package update or manually runs
+ 'grub-install', a boot entry will be added, and MAAS will lose control
+ of the system.
- ubuntu at 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
+ [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.
- 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:
+ This isn't a perfect solution - users can still call grub-install
+ manually and omit this flag.
- * 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.
+ [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.
- 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 at 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)
- ||/ Name Version Architecture Description
- +++-===============================-==============================-============-==================================================
- ii maas 2.0.0+bzr5189-0ubuntu1~16.04.1 all "Metal as a Service" is a physical cloud and IPAM
- ii maas-cert-server 0.2.25-0~64~ubuntu16.04.1 all Ubuntu certification support files for MAAS server
- ii maas-cli 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS client and command-line interface
- un maas-cluster-controller <none> <none> (no description available)
- ii maas-common 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS server common files
- ii maas-dhcp 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS DHCP server
- ii maas-dns 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS DNS server
- ii maas-proxy 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS Caching Proxy
- ii maas-rack-controller 2.0.0+bzr5189-0ubuntu1~16.04.1 all Rack Controller for MAAS
- ii maas-region-api 2.0.0+bzr5189-0ubuntu1~16.04.1 all Region controller API service for MAAS
- ii maas-region-controller 2.0.0+bzr5189-0ubuntu1~16.04.1 all Region Controller for MAAS
- un maas-region-controller-min <none> <none> (no description available)
- un python-django-maas <none> <none> (no description available)
- un python-maas-client <none> <none> (no description available)
- un python-maas-provisioningserver <none> <none> (no description available)
- ii python3-django-maas 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS server Django web framework (Python 3)
- ii python3-maas-client 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS python API client (Python 3)
- ii python3-maas-provisioningserver 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS server provisioning libraries (Python 3)
+ [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
** Description changed:
[Impact]
- Typically when you install Ubuntu on an EFI system, it installs a new default EFI boot entry that makes the system boot 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.
+ 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.
***However***, this doesn't stop a boot entry from being added after
deploy. If the user installs a grub package update or manually runs
'grub-install', a boot entry will be added, 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.
+ - 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
+ - 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
--
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/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:
[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.
***However***, this doesn't stop a boot entry from being added after
deploy. If the user installs a grub package update or manually runs
'grub-install', a boot entry will be added, 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
More information about the foundations-bugs
mailing list