2fab70c36b
Adds support to identify and utilize a CSV file to signal which bootloader to utilize, and set it when the OS is running as opposed to when EFI is running. This works around EFI loader potentially crashing some vendors hardware types when entry stored in the image does not match the EFI loader record which was utilzied to boot. Grub2+shim specifically specifically needs the CSV file name and entry label to match what the system was booted with in order to prevent the machine from potentially crashing. See https://storyboard.openstack.org/#!/story/2008962 and https://bugzilla.redhat.com/show_bug.cgi?id=1966129#c37 for more information. Change-Id: Ibf1ef4fe0764c0a6f1a39cb7eebc23ecc0ee177d Story: 2008962 Task: 42598 Co-Authored-By: Bob Fournier <bfournie@redhat.com>
23 lines
1.1 KiB
YAML
23 lines
1.1 KiB
YAML
---
|
|
features:
|
|
- |
|
|
Adds the capability into the agent to read and act upon bootloader CSV
|
|
files which serve as authoritative indicators of what bootloader to load
|
|
instead of leaning towards utilizing the default.
|
|
fixes:
|
|
- |
|
|
Fixes nodes failing after deployment completes due to issues in the Grub2
|
|
EFI loader entry addition where a ``BOOT.CSV`` file provides the
|
|
authoritative pointer to the bootloader to be used for booting the OS. The
|
|
base issue with Grub2 is that it would update the UEFI bootloader NVRAM
|
|
entries with whatever is present in a vendor specific ``BOOT.CSV`` or
|
|
``BOOTX64.CSV`` file. In some cases, a baremetal machine *can* crash when
|
|
this occurs. More information can be found at
|
|
`story 2008962 <https://storyboard.openstack.org/#!/story/2008962>`_.
|
|
issues:
|
|
- |
|
|
If multiple bootloader CSV files are present on the EFI filesystem, the
|
|
first CSV file discovered will be utilized. The Ironic team considers
|
|
multiple files to be a defect in the image being deployed. This may be
|
|
changed in the future.
|