5f7d84f483
I did something stupid when started driving forth the split of ipxe from the pxe interface: I didn't think about the need to actually separate bootloaders. In part, because the use case was a mixed Power8/Power9 and x86 cluster. Mainly because the Power hardware does not honor or care about the bootfile name provided over DHCP. The firmware knows how to read the PXELINUX boot file format and the machines are able to boot from there. Where this all goes sideways is when: * Enabled boot interfaces are set to ipxe,pxe * No default boot interface is set * Node is created without a default for x86 hardware. * Node uses ipxe boot_interface, and creates files under /httpboot * bootfile transmitted via DHCP is pxelinux.0. Fun right? The simple workaround for the power user is to just define the iPXE loader, or maybe use UEFI. But that is neither here nor there, this is still a bug and a possible use case is GRUB2 via PXE and iPXE. Not that would really work via ipxe, but hopefully people get the idea. The solution kind of seems clear, duplicate configuration and fallback if not defined. Story: #2007003 Task: #40282 Change-Id: I4419254c23095929e52a0fda11789f2f5167dc6b
18 lines
778 B
YAML
18 lines
778 B
YAML
---
|
|
upgrade:
|
|
- |
|
|
Operators upgrading from earlier versions using PXE should explicitly set
|
|
``[pxe]ipxe_bootfile_name``, ``[pxe]uefi_ipxe_bootfile_name``, and
|
|
possibly ``[pxe]ipxe_bootfile_name_by_arch`` settings, as well as a
|
|
iPXE specific ``[pxe]ipxe_config_template`` override, if required.
|
|
|
|
Setting the ``[pxe]ipxe_config_template`` to no value will result in the
|
|
``[pxe]pxe_config_template`` being used. The default value points to the
|
|
supplied standard iPXE template, so only highly customized operators may
|
|
have to tune this setting.
|
|
fixes:
|
|
- |
|
|
Addresses the lack of an ability to explicitly set different bootloaders
|
|
for ``iPXE`` and ``PXE`` based boot operations via their respective
|
|
``ipxe`` and ``pxe`` boot interfaces.
|