Discussion:
[Bug 1642298] Re: UEFI Xenial install sets computer to boot from hard disk
(too old to reply)
dann frazier
2017-01-19 21:33:56 UTC
Permalink
Though I think we really do need an OS-agnostic solution long-term, the
short(er)-term option I like the best is to introduce the
grub2/update_nvram preseed so that curtin can configure grub to not
install a boot entry in a more persistent way that survives grub package
upgrades. I discussed this w/ Ryan at a sprint last month, and he seemed
ok with it from the curtin side. Assuming that is still the case, I'll
prepare a PR for the Grub side and see if I can get that preseed option
landed.

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

** Changed in: curtin
Status: Incomplete => Confirmed

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

** Changed in: grub2 (Ubuntu)
Assignee: (unassigned) => dann frazier (dannf)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
dann frazier
2017-01-19 22:51:31 UTC
Permalink
Pull request for grub2:

The following changes since commit
fffdd1085e34858f21ba823105b655726db04aba:

Drop build-dependency on libxen-dev, unnecessary now that upstream has
taken a copy of the necessary public headers. (2016-11-05 15:45:15
+0000)

are available in the git repository at:

git://git.launchpad.net/~dannf/grub2 lp1642298

for you to fetch changes up to dabbd8feacb41ec5f8fc587c4c10ae3a62266fdc:

Add grub2/update_nvram template to allow users to disable NVRAM
updates during package upgrades (LP: #1642298). (2017-01-19 15:12:59
-0700)

----------------------------------------------------------------
dann frazier (1):
Add grub2/update_nvram template to allow users to disable NVRAM updates during package upgrades (LP: #1642298).

debian/changelog | 5 +++++
debian/config.in | 5 +++++
debian/postinst.in | 13 +++++++++++--
debian/templates.in | 10 ++++++++++
4 files changed, 31 insertions(+), 2 deletions(-)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Ubuntu Foundations Team Bug Bot
2017-01-20 00:34:33 UTC
Permalink
** Tags added: patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
dann frazier
2017-02-09 22:31:07 UTC
Permalink
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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Ryan Harper
2017-02-09 23:04:08 UTC
Permalink
Post by 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.
Can you expand on what changes are needed? Only on certain versions of
grub2 can we skip passing the flag IIF it was going to pass it?

All arches? arm-only?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
dann frazier
2017-02-10 03:23:10 UTC
Permalink
Post by 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.
Can you expand on what changes are needed? Only on certain versions of
grub2 can we skip passing the flag IIF it was going to pass it?


Good questions.

My thought is, do the preseed all the time. It won't change the behavior of
older GRUB packages, but won't hurt either. It might make sense to also
continue to do the manual grub-install --no-nvram every time. That will
also be safe with any version of GRUB.

All arches? arm-only?


It only has an effect on EFI and power systems. I know we want it on all
EFI (x86 or ARM). I don't know enough about power to say for sure, but
seems like it would also benefit. Would need to find a power/MAAS person to
confirm.

-dann

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1642298

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

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

Launchpad-Notification-Type: bug
Launchpad-Bug: product=curtin; status=Confirmed; importance=Medium;
assignee=None;
Launchpad-Bug: product=maas; status=Invalid; importance=Undecided;
assignee=None;
Launchpad-Bug: distribution=ubuntu; sourcepackage=grub2; component=main;
status=Fix Released; importance=Undecided; assignee=dann.frazier@
canonical.com;
Launchpad-Bug: distribution=ubuntu; distroseries=trusty;
sourcepackage=grub2; component=main; status=Triaged; importance=Undecided;
assignee=None;
Launchpad-Bug: distribution=ubuntu; distroseries=xenial;
sourcepackage=grub2; component=main; status=Triaged; importance=Undecided;
assignee=None;
Launchpad-Bug: distribution=ubuntu; distroseries=yakkety;
sourcepackage=grub2; component=main; status=Triaged; importance=Undecided;
assignee=None;
Launchpad-Bug-Tags: oil patch
Launchpad-Bug-Information-Type: Public
Launchpad-Bug-Private: no
Launchpad-Bug-Security-Vulnerability: no
Launchpad-Bug-Commenters: blake-rouse dannf lmic raharper rodsmith
Launchpad-Bug-Reporter: Rod Smith (rodsmith)
Launchpad-Bug-Modifier: Ryan Harper (raharper)
Launchpad-Message-Rationale: Subscriber
Launchpad-Message-For: dannf
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Ryan Harper
2017-02-10 16:27:26 UTC
Permalink
Post by Ryan Harper
Post by 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.
Can you expand on what changes are needed? Only on certain versions of
grub2 can we skip passing the flag IIF it was going to pass it?
Good questions.
My thought is, do the preseed all the time. It won't change the behavior of
What does this preseed look like?
Post by Ryan Harper
older GRUB packages, but won't hurt either. It might make sense to also
I'd like to avoid doing a dpkg-reconfigure unless it's going to do something
otherwise we're just wasting install time for platforms and versions that
don't need it.
Post by Ryan Harper
continue to do the manual grub-install --no-nvram every time. That will
also be safe with any version of GRUB.
Yes.
Post by Ryan Harper
All arches? arm-only?
It only has an effect on EFI and power systems. I know we want it on all
EFI (x86 or ARM). I don't know enough about power to say for sure, but
seems like it would also benefit. Would need to find a power/MAAS person to
confirm.
Pointer to the change of behavior? That might help explain.

We can help review and guide an MP with changes to curtin but without
one of the systems (or a way to recreate the scenario) it's not easy for
us to understand the changes needed to curtin.

Happy to discuss on irc as well, #curitn on freenode
Post by Ryan Harper
-dann
--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1642298
UEFI Xenial install sets computer to boot from hard disk
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
Launchpad-Notification-Type: bug
Launchpad-Bug: product=curtin; status=Confirmed; importance=Medium;
assignee=None;
Launchpad-Bug: product=maas; status=Invalid; importance=Undecided;
assignee=None;
Launchpad-Bug: distribution=ubuntu; sourcepackage=grub2; component=main;
canonical.com;
Launchpad-Bug: distribution=ubuntu; distroseries=trusty;
sourcepackage=grub2; component=main; status=Triaged; importance=Undecided;
assignee=None;
Launchpad-Bug: distribution=ubuntu; distroseries=xenial;
sourcepackage=grub2; component=main; status=Triaged; importance=Undecided;
assignee=None;
Launchpad-Bug: distribution=ubuntu; distroseries=yakkety;
sourcepackage=grub2; component=main; status=Triaged; importance=Undecided;
assignee=None;
Launchpad-Bug-Tags: oil patch
Launchpad-Bug-Information-Type: Public
Launchpad-Bug-Private: no
Launchpad-Bug-Security-Vulnerability: no
Launchpad-Bug-Commenters: blake-rouse dannf lmic raharper rodsmith
Launchpad-Bug-Reporter: Rod Smith (rodsmith)
Launchpad-Bug-Modifier: Ryan Harper (raharper)
Launchpad-Message-Rationale: Subscriber
Launchpad-Message-For: dannf
--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1642298
UEFI Xenial install sets computer to boot from hard disk
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
dann frazier
2017-02-10 18:31:30 UTC
Permalink
** 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.

- ***@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:
-
- ***@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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubunt
dann frazier
2017-06-14 19:13:19 UTC
Permalink
I noticed that a GRUB SRU is about to hit -updates that will trigger
this bug on existing systems. Though too late to avoid that, I did want
to recheck on the status of this bug on the curtin side.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Ryan Harper
2017-06-14 20:35:21 UTC
Permalink
I think this is related and should address things.

http://bazaar.launchpad.net/~curtin-dev/curtin/trunk/revision/503

This curtin is available in the daily PPA, and is in process for SRU'ing

https://launchpad.net/~curtin-dev/+archive/ubuntu/daily


If that's not applicable, I'm not aware of any curtin changes to address
the issue.
Post by dann frazier
I noticed that a GRUB SRU is about to hit -updates that will trigger
this bug on existing systems. Though too late to avoid that, I did want
to recheck on the status of this bug on the curtin side.
--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1642298
UEFI Xenial install sets computer to boot from hard disk
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
dann frazier
2017-06-14 21:13:27 UTC
Permalink
Cool, yeah - that looks like a more complete solution.
Post by Ryan Harper
I think this is related and should address things.
http://bazaar.launchpad.net/~curtin-dev/curtin/trunk/revision/503
This curtin is available in the daily PPA, and is in process for SRU'ing
https://launchpad.net/~curtin-dev/+archive/ubuntu/daily
If that's not applicable, I'm not aware of any curtin changes to address
the issue.
Post by dann frazier
I noticed that a GRUB SRU is about to hit -updates that will trigger
this bug on existing systems. Though too late to avoid that, I did want
to recheck on the status of this bug on the curtin side.
--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1642298
UEFI Xenial install sets computer to boot from hard disk
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1642298
UEFI Xenial install sets computer to boot from hard disk
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
Launchpad-Notification-Type: bug
Launchpad-Bug: product=curtin; status=Confirmed; importance=Medium; assignee=None;
Launchpad-Bug: product=maas; status=Invalid; importance=Undecided; assignee=None;
Launchpad-Bug: distribution=ubuntu; distroseries=trusty; sourcepackage=grub2; component=main; status=Triaged; importance=Undecided; assignee=None;
Launchpad-Bug: distribution=ubuntu; distroseries=xenial; sourcepackage=grub2; component=main; status=Triaged; importance=Undecided; assignee=None;
Launchpad-Bug: distribution=ubuntu; distroseries=yakkety; sourcepackage=grub2; component=main; status=Triaged; importance=Undecided; assignee=None;
Launchpad-Bug-Tags: oil patch
Launchpad-Bug-Information-Type: Public
Launchpad-Bug-Private: no
Launchpad-Bug-Security-Vulnerability: no
Launchpad-Bug-Commenters: blake-rouse dannf lmic raharper rodsmith
Launchpad-Bug-Reporter: Rod Smith (rodsmith)
Launchpad-Bug-Modifier: Ryan Harper (raharper)
Launchpad-Message-Rationale: Subscriber
Launchpad-Message-For: dannf
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
dann frazier
2017-06-29 16:40:24 UTC
Permalink
On Wed, Jun 14, 2017 at 3:13 PM, dann frazier
Post by dann frazier
Cool, yeah - that looks like a more complete solution.
I've tested the latest curtin daily, and found that it does not
address this problem.
While http://bazaar.launchpad.net/~curtin-dev/curtin/trunk/revision/503
seems like a good *install-time* improvement, it does not prevent a
subsequent GRUB package upgrade from making Ubuntu the default boot
entry.

We still need a runtime solution, such as having curtin set
grub2/update_nvram to False.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Rod Smith
2017-06-14 21:09:38 UTC
Permalink
I'm seeing a regression on this bug, as of 14 June 2017. If it's curtin-
common on the MAAS server that's relevant, here's the version
information:

$ dpkg -s curtin-common | grep Version
Version: 0.1.0~bzr470-0ubuntu1~16.04.1

The suggestion of creating the GRUB/Ubuntu entry but putting it lower in
the boot list than the PXE-boot option sounds fine to me, with the
caveat that some EFIs do pretty weird (buggy) things, so I suspect that
SOME systems will break. There's no way of knowing how common such
problems will be, or indeed if any really WILL break, without trying
that suggested fix.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
dann frazier
2017-06-30 16:28:08 UTC
Permalink
** Description changed:

[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.
+ *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
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://list
Blake Rouse
2017-06-30 20:06:34 UTC
Permalink
I think having MAAS tell curtin to set the grub2/update_nvram to False,
works fine. Since the path to the EFI loader should not change this is
acceptable.

Having grub adjust the EFI vars because of an upgrade is really bad in
MAAS case because a following re-deploy will no longer work.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Phillip Susi
2017-07-06 13:31:24 UTC
Permalink
If you are booting from PXE, then why install grub-efi at all?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
David Britton
2017-07-07 20:44:12 UTC
Permalink
Some Testing Scenarios and concerns before we agree that this change
should be made in curtin:

1) After this change, after curtin boots first time, is EFI boot order
a)pxe b)local disk

2) This doesn't appear scoped to grub2-efi, but modifies
grub2/update_nvram, what effect does this have on other bios/firmware
environments that rely on grub?

3) Does a new kernel install work correctly?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
dann frazier
2017-07-09 16:07:32 UTC
Permalink
On Fri, Jul 7, 2017 at 2:44 PM, David Britton
Post by David Britton
Some Testing Scenarios and concerns before we agree that this change
I'm not sure if you're asking about the design, or test results on a
given implementation, so I'll answer with respect to the design I've
proposed.
Post by David Britton
1) After this change, after curtin boots first time, is EFI boot order
a)pxe b)local disk
This proposal does not involve changing the install-time EFI boot order
at all.

As I understand it, curtin now installs a new boot entry for the
target OS - that is, it no longer passes --no-nvram to grub-install.
But, prior to reboot, it restores the previous default boot entry
(PXE). This proposal would not change this. grub2/update_nvram does
not change the behavior of grub-install called directly - just when
called by the grub maintainer scripts. Of course, this should be
verified when we have a testable implementation.
Post by David Britton
2) This doesn't appear scoped to grub2-efi, but modifies
grub2/update_nvram, what effect does this have on other bios/firmware
environments that rely on grub?
The impacted archs are described here:
https://bugs.launchpad.net/maas/+bug/1642298/comments/19

In short, EFI-based and POWER systems will be impacted. AFAICT, this
change is also beneficial for POWER, for teh same reasons, and it
should certainly be verified there before merging.
Post by David Britton
3) Does a new kernel install work correctly?
The value of grub2/update_nvram is orthogonal to a new kernel install.
A new kernel install does not trigger a call to grub-install, it just
updates the configuration of the existing grub installation
(update-grub).

-dann
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Blake Rouse
2017-07-10 16:15:00 UTC
Permalink
dann,

I think you are correct that 'grub2/update_nvram' is still not set by
curtin and an upgrade of grub could break the machine.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Mike Pontillo
2017-08-30 13:29:28 UTC
Permalink
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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Andres Rodriguez
2017-08-30 18:11:44 UTC
Permalink
Hey guys.

Sorry for joining the party late. But let me see if I understand the
full extent of the problem here.

0. A machine PXE boots off MAAS, installs Ubuntu in it, grub gets
installed and configured without updating the NVRAM.

1. The machine reboots, PXE's, boots from local disk, and finishes
installation (an unnecessary step).

2. An upgrade of <grub2 package> overwrites NVRAM to boot from disk.

3. A reboot boots from disk directly and not from network.

4. If we re-deploy, the machine is told to PXE boot via the BMC.

5. If we re-deploy the machine, the machine PXE boots off MAAS again and
installs. The machine reboots and boots off the disk.

Now, the above only becomes a real problem when. The machine does not
support changing the boot order remotely via IPMI or other power
management mechanism.

- That, however, is a certification problem. MAAS expects to be able to
control the boot order of the machine. If this is not possible, it is a
certification challenge.

That said, regardless of being able to set the boot order or not, I see
a completely different problem:

1. The administrator configured their BIOS with a specific boot order.
2. The administrator installs ubuntu, expecting their BIOS boot order configuration to remain (somewhat) unchanged (specially when it is set to boot from network first).
3. The software (grub2) overrides the BIOS' boot order to boot from disk. This overrides the fact that the administrator set the BIOS boot order to PXE first.

So, based on this, the REAL bug that needs to be fixed is that grub
needs to somewhat respect the boot order set in the BIOS. For example:

1. If BIOS Boot order before Ubuntu install is: 1. PXE, 2. HDD1, 3. HDD2
2. And we install Ubuntu on HDD2, then grub needs to /somewhat/ preserve the boot order and make it so: 1. PXE, 2. HDD2, 3. HDD1.

To conclude:
1. The real bug is in grub, and this needs to be addressed to properly preserve the boot order in a sane way if PXE/Network boot is set as the first boot type on the BIOS boot order.

2. If we want to make work arounds in the meantime, I think it is
acceptable to say that curtin should tell grub to disable nvram updating
by default, and only enabled it if the users wishes so, so we can
respect what was set on the firmware.

Either way, IMHO, the real solution is to fix grub.



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

** Changed in: maas
Importance: High => Undecided
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Rod Smith
2017-08-30 19:09:49 UTC
Permalink
Andres, fundamentally the problem is that EFI provides no means to
control the boot order via IPMI; it's set via non-IPMI firmware
mechanisms or via the efibootmgr tool in Ubuntu. That is, point #4 in
your first list is incorrect, and everything falls apart after that.
When a GRUB package uses efibootmgr to set GRUB as the default boot
option, the configuration to PXE-boot first is overridden and MAAS loses
control of the computer's boot process. Although I, the original
reporter, am on the server certification team, this isn't a
certification issue per se; it affects ANYBODY who uses MAAS to
regularly redeploy nodes. Larry Michel, then on the OIL team, noted that
it affects OIL in comment #3. Sooner or later, customers will be
affected by this, too.

You can view this as a problem with EFI and/or how IPMI interacts with
EFI if you like, but that won't resolve the problem. Like it or not, the
industry is moving to EFI, and my understanding is that the big players
in this realm aren't interested in providing a way for IPMI to set the
boot order on EFI-based systems. Even if they did, at this late date
there'd still be a large installed base of computers that wouldn't work
with any mechanism that might be developed.

What we (Canonical) CAN control is how and when we use efibootmgr to
adjust the boot order. This is PARTLY a GRUB packaging issue, but we
need some way to tell that package whether or not to set itself as the
default boot option. Blake, Ryan, and Dann are discussing ways to use
debconf variables to tell the GRUB package what to do, and if I'm
understanding correctly, MAAS will have to set such a variable in a
preseed file to produce results that keep nodes controllable by MAAS.

Of course, once a node is deployed, its owner could log in and mess
things up. There's not much we can do about that, but at least we can
ensure that our own tools and procedures don't mess things up.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Andres Rodriguez
2017-08-30 19:44:44 UTC
Permalink
Hi Rod,

Judging by your message in #2, unless I'm missing something, you would have not been able to re-deploy the machine because efibootmgr had set the boot order to the disk first. When you re-deployed the machine, MAAS told that machine that "on the next boot, PXE boot".
"
- 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.
"

As far as IPMI, you do have a way to ensure that the next boot, boots
from PXE. Example EFI boot config for freeipmi-tools:

Section Chassis_Boot_Flags
Boot_Flags_Persistent Yes
BIOS_Boot_Type EFI
Boot_Device PXE
EndSection


And exactly, we as Canonical can control how and when we use efibootmgr to adjust the boot order. The fact that we are, by default, completely eliminating the boot order that has been set on the BIOS by the administrator, is IMHO, the wrong approach. If the administrator has, by default, set PXE as the first in the boot order, then grub should not be overriding such configuration. There is a reason why the administrator has set the boot order to PXE first and Ubuntu shouldn't be changing that.

While I understand you guys have been discussing the solution, and
whatever the solution may be, that doesn't change the fact that both
Blake and I agree in the fact that grub shouldn't be changing the boot
order by default. The fact that it is currently doing it overriding BIOS
settings and we want to work around it, is a completely different
matter. Also, it doesn't mean that curtin shouldn;t be setting this by
default. IMHO, as I already expressed, curtin should ensure setting the
grub to not update the nvram to ensure that curtin maintains what it
does today.

Today, after installation, curtin uses efibootmgr *AND* ensures that PXE
is first on the boot order, and the disk is second as a fallback. As
such, curtin needs to ensure, by default that grub does not overwrite
the efibootmgr configuration that curtin already made.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
dann frazier
2017-08-30 20:41:04 UTC
Permalink
On Wed, Aug 30, 2017 at 1:44 PM, Andres Rodriguez
Post by Andres Rodriguez
Hi Rod,
Judging by your message in #2, unless I'm missing something, you would have not been able to re-deploy the machine because efibootmgr had set the boot order to the disk first. When you re-deployed the machine, MAAS told that machine that "on the next boot, PXE boot".
"
- 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.
"
As far as IPMI, you do have a way to ensure that the next boot, boots
Section Chassis_Boot_Flags
Boot_Flags_Persistent Yes
BIOS_Boot_Type EFI
Boot_Device PXE
EndSection
hey Andres,

The BIOS_Boot_Type and Boot_Device fields are mutually exclusive. If a
system supports both EFI and Legacy mode, BIOS_Boot_Type allows you to
choose between them. Boot_Device only works when booting in Legacy
mode - See section 28.13 of the IPMI Spec. It has no effect in EFI
mode for any implementation I've seen.

- dann
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Andres Rodriguez
2017-08-30 21:03:18 UTC
Permalink
In ipmitool 1.18.17+

$ ipmitool -I lanplus -U xxx -P xxx -H X.X.X.X chassis bootdev pxe options=persistent,efiboot
Set Boot Device to pxe

$ ipmitool -I lanplus -U xxx -P xxx -H X.X.X.X chassis bootparam get 5
Boot parameter version: 1
Boot parameter 5 is valid/unlocked
Boot parameter data: a004020000
Boot Flags :
- Boot Flag Valid
- Options apply to only next boot
- BIOS EFI boot
- Boot Device Selector : Force PXE
- Console Redirection control : System Default
- Lock Out Sleep Button
- BIOS verbosity : Request console redirection be enabled
- BIOS Mux Control Override : BIOS uses recommended setting of the mux at the end of POST
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
David Britton
2017-08-30 21:13:23 UTC
Permalink
14:34 rharper │ http://curtin.readthedocs.io/en/latest/topics/config.html#debconf-selections
14:34 rharper │ we already have a generic debconf-selections in curtin, so I believe maas could just send the grub value needed to
│ control the grub2 behavior
14:35 dpb │ rharper: ooooh, beautiful
14:35 roaksoax │ rharper: cool
From IRC above. I believe with this, the MAAS task should be considered
as new.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubu
Andres Rodriguez
2017-08-30 21:13:27 UTC
Permalink
** Summary changed:

- UEFI Xenial install sets computer to boot from hard disk
+ Grub upgrades overwrites NVRAM cuasing MAAS/curtin boot order to be overwriten
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
David Britton
2017-08-30 21:13:36 UTC
Permalink
** Changed in: maas
Status: Incomplete => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Andres Rodriguez
2017-08-30 21:13:56 UTC
Permalink
The work around is to pass a debconf configuration option to grub2
package to not update the NVRAM on package upgrade.

** Changed in: maas
Assignee: (unassigned) => Andres Rodriguez (andreserl)

** Changed in: maas
Status: New => Confirmed

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

** Summary changed:

- Grub upgrades overwrites NVRAM cuasing MAAS/curtin boot order to be overwriten
+ Grub package upgrades overwrites NVRAM, causing MAAS boot order to be overwritten.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Rod Smith
2017-08-30 21:18:59 UTC
Permalink
Andres, it's perfectly possible to redeploy a system after it's been set
to boot from the local disk by either adjusting the boot order on the
node or by deleting GRUB from the local disk. I don't recall which of
those I did in the procedure noted in my comment #2, but it was likely
one of those things; I simply didn't mention it; probably I thought it
was obvious that I was working around the problem.

I'm not familiar with freeipmi-tools; however, I've just tested the
following with ipmitool, and neither forced a server to PXE-boot:

ipmitool -H 10.20.30.13 -I lanplus -U user -P pass chassis bootparam set force_pxe
ipmitool -H 10.20.30.13 -I lanplus -U pass -P pass chassis bootdev pxe

Both times, ipmitool reported that the node was set to PXE-boot, but in
both cases, the boot order reported by efibootmgr did not change, and
when I rebooted, the node booted from the first item on that list (that
is, not PXE-booting). I verified the boot order both by watching the
boot process on the terminal and noting no PXE-boot attempt and by
verifying via efibootmgr, once the system was up, that the BootCurrent
variable was set to the "ubuntu" entry, not to a PXE-boot entry. I did
this testing on betelnut, a Dell PowerEdge T110 in Lexington.

As to what GRUB should be doing on installation, that's different for
MAAS vs. a non-network install (say, your laptop). EFI is explicitly
designed to support multiple boot loaders on a disk, so an OS that
installs in a non-PXE-boot way *MUST* register itself with the firmware,
and in practice, OSes normally set their boot loaders as the default.
Thus, changes to the boot order on OS installation are normal and
expected behavior in the EFI world. MAAS is the special case here; if a
MAAS-deployed OS should continue to boot with the help of the MAAS
server, then the OS should either not register itself or register itself
but ensure that the PXE-boot option(s) come earlier in the boot list
than the local boot loader.

Note that, back in February, Dann Frazier submitted a change to GRUB
and/or curtin that fixed this bug by causing the behavior you describe
as optimal -- that is, the GRUB package no longer touched the EFI boot
order when it was installed from the network, and it kept a debconf
variable to ensure that future GRUB updates didn't cause problems (those
updates, really, are the problem). (I don't see Dann's changes linked
from this bug report, but maybe I'm missing something.) That, however,
caused nodes to fail to boot if the MAAS server became inaccessible,
since then there was no fallback to boot from GRUB on the hard disk. I
believe somebody filed a bug on that, but I don't have a reference. Dann
noted in comment #21 to this bug report that a GRUB SRU was imminent
that would likely cause a regression on THIS bug, and in comment #23, I
confirmed that this was the case.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Rod Smith
2017-08-30 21:32:40 UTC
Permalink
Ooh, lots of activity while I typed my last comment.

This may be beating a dead horse, but concerning comment #42, Andres, I
tried that command and got similar output:

$ ipmitool -H 10.20.30.13 -I lanplus -U user -P pass chassis bootdev pxe options=persistent,efiboot
Set Boot Device to pxe
$ ipmitool -H 10.20.30.13 -I lanplus -U user -P pass chassis bootparam get 5
Boot parameter version: 1
Boot parameter 5 is valid/unlocked
Boot parameter data: a004000000
Boot Flags :
- Boot Flag Valid
- Options apply to only next boot
- BIOS EFI boot
- Boot Device Selector : Force PXE
- Console Redirection control : System Default
- BIOS verbosity : Console redirection occurs per BIOS configuration setting (default)
- BIOS Mux Control Override : BIOS uses recommended setting of the mux at the end of POST

On the node, efibootmgr showed an unchanged boot order, and it continued
to boot from the hard disk without PXE-booting. What's more, on reboot I
noticed that ipmitool claimed the system would boot in legacy mode:

$ ipmitool -H 10.20.30.13 -I lanplus -U user -P pass chassis bootparam get 5
Boot parameter version: 1
Boot parameter 5 is valid/unlocked
Boot parameter data: 0000000000
Boot Flags :
- Boot Flag Invalid
- Options apply to only next boot
- BIOS PC Compatible (legacy) boot
- Boot Device Selector : No override
- Console Redirection control : System Default
- BIOS verbosity : Console redirection occurs per BIOS configuration setting (default)
- BIOS Mux Control Override : BIOS uses recommended setting of the mux at the end of POST

(Note the "BIOS PC Compatible (legacy) boot" line.) On reboot, the
system booted in EFI mode. I see similar things on other nodes that are
configured to boot in EFI mode. Thus, you really can't trust what IPMI
tells you (or what you tell it) about boot mode or boot device on an
EFI-based computer.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Blake Rouse
2017-08-31 13:32:00 UTC
Permalink
I think this is more of a GRUB issue overall instead of a MAAS issue
directly. True it affects MAAS and we can do the debconf selections to
work around this issue but overall for quality of Ubuntu I do not
believe this is the proper fix.

I will give an example without MAAS.

1. First the user installs Ubuntu on a partition on their local disk, EFI is updated so Ubuntu can boot.
2. Second the user installs Windows on another partition. EFI is updates so Windows can boot and its first.
3. User reboots into Ubuntu, runs apt-get, and grub updates changing the boot order so now that Ubuntu boots first.
4. User reboots their machine and Ubuntu boots but the user expected Windows to boot.

Overall this is a bad experience to the user.

I think the grub code should be smart about this:

First check if the grub.efi loader already exists in efibootmgr. If it
does not exists add it to the loader and set it to boot first. If it
does exist record its current place in the boot order, update the loader
and reset the boot order to its previous location.

That change would fix this for any user that uses Ubuntu as well as MAAS
users.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
David Britton
2017-08-31 14:17:24 UTC
Permalink
Hi Blake --

Could you please redirect that discussion to:

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1714090? Which has
been opened to discuss making grub2 UX better on Ubuntu.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Rod Smith
2017-08-31 14:34:09 UTC
Permalink
Blake, your proposal makes sense on the surface; however, there are
cases where it would cause problems. For instance, suppose that, outside
of a MAAS environment, somebody installs Ubuntu, then installs Windows
in a dual-boot configuration, then re-installs Ubuntu because Windows
grabbed the boot process and the user couldn't figure out how to boot
into Ubuntu. In this case, Ubuntu/GRUB would not then gain control of
the boot process, which is what the user was hoping would happen, and (I
THINK) what would happen today. Of course, re-installing Ubuntu was
overkill in this scenario, and a little knowledge would go a long way to
resolving the problem in an easier way; but I've seen posts on user
forums from new users who do things like this. This isn't to say that
your suggestion is a bad one; but implementing it would create some new
problems of its own. They might be smaller than the ones we've got now,
but they should be considered.

Three more points, should Blake's proposal be implemented:

First, and most importantly, the initial installation of GRUB in a MAAS
environment would get it wrong, since as outlined, the proposal would
give boot control to the local hard disk, which is exactly the problem
we want to avoid. In such an environment, you'd need to install GRUB and
ensure that it comes AFTER the PXE-boot option, otherwise the initial
problem (MAAS losing control of nodes' boot process) would exist. Thus,
either the GRUB package would need to take a cue from MAAS to leave the
current top boot option in control (that is, install GRUB as the second
or later boot option) or it would need enough smarts to figure this out
itself. Given the wide variation in the way PXE-boot options appear in
efibootmgr output, the former is likely to be more reliable than the
latter.

Second, there's a potential implementation pitfall: There might be
stale/invalid NVRAM entries that point to GRUB on non-existent devices.
This could happen when MAAS redeploys a node, since the partition table
will be wiped and new partitions created, but the NVRAM-based boot
entries will be untouched. (Analogous things can happen in local/manual
installations, too, of course.) The new EFI System Partition (ESP) will
have a new GUID, which won't match the old one for the original
installation. Thus, if the check for a reference to grubx64.efi doesn't
include the GUID value (at a minimum; there are other identifying
features, too), it might think the existing entry is valid, when in fact
it's not. (Note that some, but not all, EFIs wipe invalid boot entries,
so some computers might not exhibit this problem, but others will.)

Third, on systems that boot with Secure Boot active, the NVRAM entry
will normally point to shimx64.efi, not grubx64.efi. In fact, this is
usually the case even when Secure Boot is NOT active, or is unavailable;
but with Secure Boot out of the picture, either binary should work to
boot the computer.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Blake Rouse
2017-08-31 19:15:40 UTC
Permalink
Rod,

I moved my comment to the other bug. But to respond to your comments.

I think your point about #1 is something that should be solved during
installation. There is no reason the Ubuntu installation cannot be smart
enough to re-order the boot order. I think on fresh install that makes
perfect sense, but on an upgrade of an existing package this should not
occur.

#2 I agree the bootloader would need to be a direct match. GUID and
path.

#3 Yeah using the shimx64 is what you want. My suggestion was more of a
suggestion on how it should work over all. I was being over specific
with grubx64.efi.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Launchpad Bug Tracker
2017-09-13 04:30:56 UTC
Permalink
** Merge proposal linked:
https://code.launchpad.net/~andreserl/maas/+git/maas/+merge/330644
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
ht
Andres Rodriguez
2017-09-13 04:38:16 UTC
Permalink
** Changed in: maas
Status: Confirmed => In Progress

** Also affects: maas/2.2
Importance: Undecided
Status: New

** Changed in: maas/2.2
Milestone: None => 2.2.3

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

** Changed in: maas/2.2
Status: New => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mai
MAAS Lander
2017-09-14 21:36:51 UTC
Permalink
** Changed in: maas
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/l
dann frazier
2017-09-14 22:05:12 UTC
Permalink
** Changed in: grub2 (Ubuntu Yakkety)
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com
Andres Rodriguez
2017-09-15 19:25:21 UTC
Permalink
** Changed in: maas
Milestone: 2.3.0 => 2.3.0alpha3
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/
Andres Rodriguez
2017-09-18 14:44:21 UTC
Permalink
** Changed in: maas
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/
dann frazier
2017-09-25 15:32:12 UTC
Permalink
Thanks Andres! I've verified that this is working as designed when
deploying zesty. I've prepared an SRU for GRUB in xenial and verified
that it also behaves correctly, so I'll go ahead and upload that.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://l
Po-Hsu Lin
2017-09-26 03:00:59 UTC
Permalink
I found this issue again on Xenial,
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1719271
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
h
Phillip Susi
2017-10-04 18:56:20 UTC
Permalink
So I guess nobody saw my question before. If you are booting with PXE,
then why don't you just not install grub-efi in the first place?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubun
dann frazier
2017-10-04 19:34:49 UTC
Permalink
@psusi because the only thing we boot from PXE is a GRUB that chainloads
to the GRUB on disk. We need the GRUB on disk to boot the
kernel/ramdisk/cmdline installed by the OS.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/list
Brian Murray
2017-10-05 18:00:08 UTC
Permalink
The uploading purporting to fix this bug is blocked on the verification
of the existing grub2 SRU for bug 1716424.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinf
Brian Murray
2017-10-12 20:27:03 UTC
Permalink
Hello Rod, or anyone else affected,

Accepted grub2 into xenial-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/grub2/2.02~beta2-36ubuntu3.14 in a
few hours, and then in the -proposed repository.

Please help us by testing this new package. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-xenial to verification-done-xenial. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-xenial. In either case, details of your
testing will help us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance!

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

** Tags added: verification-needed verification-needed-xenial
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu
Brian Murray
2017-10-12 20:30:54 UTC
Permalink
Hello Rod, or anyone else affected,

Accepted grub2-signed into xenial-proposed. The package will build now
and be available at
https://launchpad.net/ubuntu/+source/grub2-signed/1.66.14 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-xenial to verification-done-xenial. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-xenial. In either case, details of your
testing will help us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance!

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

** Changed in: grub2-signed (Ubuntu Xenial)
Status: New => Fix Committed

** Changed in: grub2-signed (Ubuntu)
Status: New => Fix Released

** Changed in: grub2-signed (Ubuntu Yakkety)
Status: New => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubun
dann frazier
2017-10-13 22:05:36 UTC
Permalink
SRU verification[*]:

***@dawes:~$ sudo efibootmgr | grep ubuntu
***@dawes:~$ sudo debconf-show grub-efi-arm64 | grep update_nvram
grub2/update_nvram: true
***@dawes:~$ sudo dpkg-reconfigure -pcritical grub-efi-arm64
Installing for arm64-efi platform.
Installation finished. No error reported.
Generating grub configuration file ...
Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
Found linux image: /boot/vmlinuz-4.4.0-97-generic
Found initrd image: /boot/initrd.img-4.4.0-97-generic
Adding boot menu entry for EFI firmware configuration
done
***@dawes:~$ sudo efibootmgr | grep ubuntu
Boot0000* ubuntu
***@dawes:~$ sudo efibootmgr -B -b 0000 > /dev/null


***@dawes:~$ echo debconf grub2/update_nvram boolean false | sudo debconf-set-selections
***@dawes:~$ sudo debconf-show grub-efi-arm64 | grep update_nvram
* grub2/update_nvram: false
***@dawes:~$ sudo efibootmgr | grep ubuntu
***@dawes:~$ sudo dpkg-reconfigure -pcritical grub-efi-arm64
Installing for arm64-efi platform.
Installation finished. No error reported.
Generating grub configuration file ...
Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
Found linux image: /boot/vmlinuz-4.4.0-97-generic
Found initrd image: /boot/initrd.img-4.4.0-97-generic
Adding boot menu entry for EFI firmware configuration
done
***@dawes:~$ sudo efibootmgr | grep ubuntu
***@dawes:~$

[*] Note: the arm64/amd64 builds are still stuck in "Unapproved" - I did
this verification by pulling the builds from LP directly


** Tags removed: verification-needed verification-needed-xenial
** Tags added: verification-done verification-done-xenial
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://list
Launchpad Bug Tracker
2017-10-26 15:24:36 UTC
Permalink
This bug was fixed in the package grub2 - 2.02~beta2-36ubuntu3.14

---------------
grub2 (2.02~beta2-36ubuntu3.14) xenial; urgency=medium

* Add grub2/update_nvram template to allow users to disable NVRAM
updates during package upgrades (LP: #1642298).

-- dann frazier <***@ubuntu.com> Thu, 14 Sep 2017 16:13:39 -0600

** Changed in: grub2 (Ubuntu Xenial)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mai
Łukasz Zemczak
2017-10-26 15:24:47 UTC
Permalink
The verification of the Stable Release Update for grub2 has completed
successfully and the package has now been released to -updates.
Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report. In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/lis
Launchpad Bug Tracker
2017-10-26 15:24:51 UTC
Permalink
This bug was fixed in the package grub2-signed - 1.66.14

---------------
grub2-signed (1.66.14) xenial; urgency=medium

* Rebuild against grub2 2.02~beta2-36ubuntu3.14. (LP: #1642298)

-- dann frazier <***@canonical.com> Mon, 25 Sep 2017 09:36:55
-0600

** Changed in: grub2-signed (Ubuntu Xenial)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/m
Po-Hsu Lin
2018-02-21 06:23:39 UTC
Permalink
Potential regression found on Xenial, bug 1750732
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu
Andres Rodriguez
2018-02-21 17:52:38 UTC
Permalink
** Changed in: maas/2.2
Status: Triaged => Won't Fix

** Changed in: maas/2.2
Milestone: 2.2.3 => None
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1642298

Title:
Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
overwritten.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo
Loading...