Comment 11 for bug 1642298

I'm afraid that the problem has disappeared for me. It had been occurring quite reliably on our MAAS server and our one EFI system in 1SS, but it just stopped happening late last week. Following Larry's comment in an e-mail thread that he had no problem with a Trusty deployment, I tried that, but (probably coincidentally), the problem disappeared then and has not recurred with subsequent Xenial deployments, either. This is frustrating, of course, since we need to be able to reliably reproduce the problem to fix it.

That said, it occurred to me that there is a "nuclear option" that SHOULD eliminate the problem altogether: Pass "noefi" to the kernel as a default option, at least on EFI-based computers. This kernel option disables access to the EFI variable store, which should make it impossible for Ubuntu tools to adjust the boot order.

The down side, of course, is that this will also make it impossible to take advantage of EFI-specific features that might be desirable -- it won't be possible to check the boot order, check whether Secure Boot is active, use fwupdate to update firmware, etc. I have tested it on deployments of both an EFI-based and a BIOS-only computer (via the "Global Kernel Parameters" field at http://localhost/MAAS/settings/ on the MAAS server) and it does seem to disable efibootmgr as expected on the EFI system, while causing no obvious problems on the BIOS system. Because the problem has disappeared for me, I can't confirm that it will definitely solve the problem.

There are at least three ways this option might be employed:

* On ephemerals -- Unless the ephemerals used for enlistment, commissioning,
  and deployment require access to EFI variables, passing "noefi" to their
  kernels by default makes sense; this practice should prevent accidentally
  setting EFI variables inappropriately during deployment.
* As a default on installed systems -- MAAS could set this option as a
  default on all deployed systems. Because of the down sides just mentioned,
  I'm reluctant to advocate for this, but it may deserve consideration.
* On an installation-by-installation basis -- Individual administrators
  can set this option, as I did in my tests, if they run into this bug.
  This would basically be an individual workaround for this bug until
  a better resolution is reached.

One question I have is whether the kernel options set via the "Global Kernel Parameters" field in the web UI apply to the ephemerals. If they don't, and if the problem is occurring late in deployment (but before the system reboots into the installed system), then setting "noefi" in that field will not be a useful workaround for this bug.