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:
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.
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 Persistent Yes
Boot_Flags_
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.