Grub package upgrades overwrites NVRAM, causing MAAS boot order to be overwritten.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MAAS |
Fix Released
|
High
|
Andres Rodriguez | ||
2.2 |
Won't Fix
|
High
|
Unassigned | ||
curtin |
Invalid
|
Medium
|
Unassigned | ||
grub2 (Ubuntu) |
Fix Released
|
Undecided
|
dann frazier | ||
Trusty |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
Yakkety |
Won't Fix
|
Undecided
|
Unassigned | ||
grub2-signed (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Trusty |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
Yakkety |
Won't Fix
|
Undecided
|
Unassigned |
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/
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-
- 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/
- XXX curtin risk XXX
Related branches
- Blake Rouse (community): Approve
-
Diff: 38 lines (+17/-0)2 files modifiedsrc/maasserver/preseed.py (+7/-0)
src/maasserver/tests/test_preseed.py (+10/-0)
Changed in maas: | |
status: | New → Invalid |
Changed in curtin: | |
importance: | Undecided → Medium |
status: | New → Incomplete |
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). |
tags: | added: patch |
description: | updated |
description: | updated |
description: | updated |
summary: |
- UEFI Xenial install sets computer to boot from hard disk + Grub upgrades overwrites NVRAM cuasing MAAS/curtin boot order to be + overwriten |
Changed in maas: | |
status: | Incomplete → New |
Changed in maas: | |
status: | Confirmed → In Progress |
Changed in maas: | |
status: | In Progress → Fix Committed |
Changed in grub2 (Ubuntu Yakkety): | |
status: | Triaged → Won't Fix |
Changed in maas: | |
milestone: | 2.3.0 → 2.3.0alpha3 |
Changed in maas: | |
status: | Fix Committed → Fix Released |
Changed in curtin: | |
status: | Confirmed → Invalid |
Some more information:
I've tried with another computer on another MAAS 2.0 server. What I discovered:
- The node was already deployed and running when I started. It had the
"ubuntu" entry set as the default in "efibootmgr" output, suggesting
that when it was last deployed (about a month ago?), the bug existed.
- I redeployed, and it worked as expected.
It's starting to look as if either the bug may have existed for a while but been corrected recently or it's rather inconsistent in the conditions that cause it to appear.