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-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
