2016-11-16 15:27:47 |
Rod Smith |
bug |
|
|
added bug |
2016-11-16 15:27:47 |
Rod Smith |
attachment added |
|
/var/log/maas directory tree from the server https://bugs.launchpad.net/bugs/1642298/+attachment/4778199/+files/var-log-maas.tgz |
|
2016-11-17 20:04:52 |
Larry Michel |
tags |
|
oil |
|
2016-11-17 22:00:33 |
Andres Rodriguez |
bug task added |
|
curtin |
|
2016-11-17 22:00:43 |
Andres Rodriguez |
maas: status |
New |
Invalid |
|
2016-11-17 22:24:56 |
Jon Grimm |
bug |
|
|
added subscriber Jon Grimm |
2016-11-17 22:35:46 |
Ryan Harper |
curtin: importance |
Undecided |
Medium |
|
2016-11-17 22:35:46 |
Ryan Harper |
curtin: status |
New |
Incomplete |
|
2016-11-17 23:20:15 |
Rod Smith |
attachment added |
|
maas admin machine get-curtin-config node-71680a80-0be9-11e6-9e07-0023aeff4e6f https://bugs.launchpad.net/maas/+bug/1642298/+attachment/4778873/+files/wildorange-curtin-config.txt |
|
2016-11-17 23:24:20 |
Rod Smith |
attachment added |
|
wildorange-installation-output.txt https://bugs.launchpad.net/maas/+bug/1642298/+attachment/4778874/+files/wildorange-installation-output.txt |
|
2016-11-18 14:15:59 |
Andres Rodriguez |
summary |
MAAS UEFI install sets computer to boot from hard disk |
UEFI Xenial install sets computer to boot from hard disk (doesn't happen with trusty). |
|
2016-11-21 17:41:21 |
Larry Michel |
summary |
UEFI Xenial install sets computer to boot from hard disk (doesn't happen with trusty). |
UEFI Xenial install sets computer to boot from hard disk |
|
2016-11-22 00:18:58 |
dann frazier |
attachment added |
|
grub2-debconf-update-nvram.patch https://bugs.launchpad.net/maas/+bug/1642298/+attachment/4781276/+files/grub2-debconf-update-nvram.patch |
|
2016-11-22 17:41:08 |
dann frazier |
bug |
|
|
added subscriber dann frazier |
2016-12-09 13:52:15 |
Rod Smith |
attachment added |
|
/etc/maas/preseeds/curtin_userdata file used to force a GRUB update as part of the installation https://bugs.launchpad.net/maas/+bug/1642298/+attachment/4789531/+files/curtin_userdata |
|
2017-01-19 21:33:46 |
dann frazier |
bug task added |
|
grub2 (Ubuntu) |
|
2017-01-19 21:35:05 |
dann frazier |
curtin: status |
Incomplete |
Confirmed |
|
2017-01-19 21:35:07 |
dann frazier |
grub2 (Ubuntu): status |
New |
Confirmed |
|
2017-01-19 21:35:10 |
dann frazier |
grub2 (Ubuntu): assignee |
|
dann frazier (dannf) |
|
2017-01-20 00:34:33 |
Ubuntu Foundations Team Bug Bot |
tags |
oil |
oil patch |
|
2017-02-09 22:32:34 |
dann frazier |
nominated for series |
|
Ubuntu Yakkety |
|
2017-02-09 22:32:34 |
dann frazier |
bug task added |
|
grub2 (Ubuntu Yakkety) |
|
2017-02-09 22:32:34 |
dann frazier |
nominated for series |
|
Ubuntu Xenial |
|
2017-02-09 22:32:34 |
dann frazier |
bug task added |
|
grub2 (Ubuntu Xenial) |
|
2017-02-09 22:32:51 |
dann frazier |
nominated for series |
|
Ubuntu Trusty |
|
2017-02-09 22:32:51 |
dann frazier |
bug task added |
|
grub2 (Ubuntu Trusty) |
|
2017-02-09 22:33:04 |
dann frazier |
grub2 (Ubuntu): status |
Confirmed |
Fix Released |
|
2017-02-09 22:33:09 |
dann frazier |
grub2 (Ubuntu Trusty): status |
New |
Triaged |
|
2017-02-09 22:33:12 |
dann frazier |
grub2 (Ubuntu Yakkety): status |
New |
Triaged |
|
2017-02-09 22:33:14 |
dann frazier |
grub2 (Ubuntu Xenial): status |
New |
Triaged |
|
2017-02-10 18:31:30 |
dann frazier |
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)
||/ 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) |
[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.
***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 |
|
2017-02-10 18:31:46 |
dann frazier |
description |
[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.
***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 |
[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 |
|
2017-06-15 07:28:09 |
Andrew Cloke |
bug |
|
|
added subscriber Andrew Cloke |
2017-06-28 21:05:22 |
Sean Sosik-Hamor |
bug |
|
|
added subscriber The Canonical Sysadmins |
2017-06-29 07:54:45 |
Junien F |
bug |
|
|
added subscriber Junien Fridrick |
2017-06-30 16:28:08 |
dann frazier |
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 |
[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 |
|
2017-08-30 13:28:44 |
Mike Pontillo |
maas: status |
Invalid |
Triaged |
|
2017-08-30 13:28:48 |
Mike Pontillo |
maas: importance |
Undecided |
High |
|
2017-08-30 13:28:52 |
Mike Pontillo |
maas: milestone |
|
2.3.0 |
|
2017-08-30 18:11:55 |
Andres Rodriguez |
maas: status |
Triaged |
Incomplete |
|
2017-08-30 18:12:02 |
Andres Rodriguez |
maas: importance |
High |
Undecided |
|
2017-08-30 21:13:27 |
Andres Rodriguez |
summary |
UEFI Xenial install sets computer to boot from hard disk |
Grub upgrades overwrites NVRAM cuasing MAAS/curtin boot order to be overwriten |
|
2017-08-30 21:13:36 |
David Britton |
maas: status |
Incomplete |
New |
|
2017-08-30 21:14:01 |
Andres Rodriguez |
maas: assignee |
|
Andres Rodriguez (andreserl) |
|
2017-08-30 21:14:03 |
Andres Rodriguez |
maas: status |
New |
Confirmed |
|
2017-08-30 21:14:07 |
Andres Rodriguez |
maas: importance |
Undecided |
High |
|
2017-08-30 21:14:33 |
Andres Rodriguez |
summary |
Grub upgrades overwrites NVRAM cuasing MAAS/curtin boot order to be overwriten |
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be overwritten. |
|
2017-09-13 04:30:56 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~andreserl/maas/+git/maas/+merge/330644 |
|
2017-09-13 04:38:16 |
Andres Rodriguez |
maas: status |
Confirmed |
In Progress |
|
2017-09-13 04:38:21 |
Andres Rodriguez |
nominated for series |
|
maas/2.2 |
|
2017-09-13 04:38:21 |
Andres Rodriguez |
bug task added |
|
maas/2.2 |
|
2017-09-13 04:38:35 |
Andres Rodriguez |
maas/2.2: milestone |
|
2.2.3 |
|
2017-09-13 04:38:38 |
Andres Rodriguez |
maas/2.2: importance |
Undecided |
High |
|
2017-09-13 04:38:41 |
Andres Rodriguez |
maas/2.2: status |
New |
Triaged |
|
2017-09-14 21:36:51 |
MAAS Lander |
maas: status |
In Progress |
Fix Committed |
|
2017-09-14 22:05:12 |
dann frazier |
grub2 (Ubuntu Yakkety): status |
Triaged |
Won't Fix |
|
2017-09-15 19:25:21 |
Andres Rodriguez |
maas: milestone |
2.3.0 |
2.3.0alpha3 |
|
2017-09-18 14:44:21 |
Andres Rodriguez |
maas: status |
Fix Committed |
Fix Released |
|
2017-10-12 20:26:45 |
Brian Murray |
grub2 (Ubuntu Xenial): status |
Triaged |
Fix Committed |
|
2017-10-12 20:26:49 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
2017-10-12 20:26:53 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
2017-10-12 20:27:02 |
Brian Murray |
tags |
oil patch |
oil patch verification-needed verification-needed-xenial |
|
2017-10-12 20:31:13 |
Brian Murray |
bug task added |
|
grub2-signed (Ubuntu) |
|
2017-10-12 20:31:34 |
Brian Murray |
grub2-signed (Ubuntu Xenial): status |
New |
Fix Committed |
|
2017-10-12 20:31:54 |
Brian Murray |
grub2-signed (Ubuntu): status |
New |
Fix Released |
|
2017-10-12 20:32:14 |
Brian Murray |
grub2-signed (Ubuntu Yakkety): status |
New |
Won't Fix |
|
2017-10-13 22:05:56 |
dann frazier |
tags |
oil patch verification-needed verification-needed-xenial |
oil patch verification-done verification-done-xenial |
|
2017-10-26 15:24:36 |
Launchpad Janitor |
grub2 (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
2017-10-26 15:24:46 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
2017-10-26 15:24:51 |
Launchpad Janitor |
grub2-signed (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
2018-02-21 17:52:38 |
Andres Rodriguez |
maas/2.2: status |
Triaged |
Won't Fix |
|
2018-02-21 17:52:38 |
Andres Rodriguez |
maas/2.2: milestone |
2.2.3 |
|
|
2018-12-12 00:56:09 |
Launchpad Janitor |
grub2-signed (Ubuntu Trusty): status |
New |
Confirmed |
|
2019-01-15 23:01:11 |
Brian Murray |
grub2 (Ubuntu Trusty): status |
Triaged |
Fix Committed |
|
2019-01-15 23:01:16 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
2019-01-15 23:01:25 |
Brian Murray |
tags |
oil patch verification-done verification-done-xenial |
oil patch verification-done-xenial verification-needed verification-needed-trusty |
|
2019-01-15 23:05:08 |
Brian Murray |
grub2-signed (Ubuntu Trusty): status |
Confirmed |
Fix Committed |
|
2019-01-16 16:36:45 |
dann frazier |
tags |
oil patch verification-done-xenial verification-needed verification-needed-trusty |
oil patch verification-done verification-done-trusty verification-done-xenial |
|
2019-02-04 12:08:15 |
Launchpad Janitor |
grub2 (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
2019-02-04 12:08:28 |
Launchpad Janitor |
grub2-signed (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
2021-03-18 05:06:42 |
Po-Hsu Lin |
curtin: status |
Confirmed |
Invalid |
|