1. boot order (e.g. pxe, disk, usb, cdrom, etc)
2. boot method (legacy or efi).
So, with this issue, what we are saying is that when using a tool to manage the BMC remotely, it will *NOT* respect the settings that have been manually set by the administrator in the BIOS itself. For example, if the administrator sets:
1. boot order - disk first, pxe second
2. boot method - efi
3. ipmitool -I lanplus -H <iLO ip> -U admin -P admin123 chassis bootdev pxe
And then the administrator uses ipmitool/freeipmi-tools to tell the machine to PXE boot the next time instead of boot from disk, then it will *NOT* respect the fact that the boot method is EFI, and it will boot in legacy mode instead.
To me, this seems like a critical issue that the firmware *automatically* decides to overwrite the setting in the *bios*, without the user specifically requesting to do so.
I would think this is something that needs to be fixed in the IPMI spec.
So i think there are different variables here:
1. boot order (e.g. pxe, disk, usb, cdrom, etc)
2. boot method (legacy or efi).
So, with this issue, what we are saying is that when using a tool to manage the BMC remotely, it will *NOT* respect the settings that have been manually set by the administrator in the BIOS itself. For example, if the administrator sets:
1. boot order - disk first, pxe second
2. boot method - efi
3. ipmitool -I lanplus -H <iLO ip> -U admin -P admin123 chassis bootdev pxe
And then the administrator uses ipmitool/ freeipmi- tools to tell the machine to PXE boot the next time instead of boot from disk, then it will *NOT* respect the fact that the boot method is EFI, and it will boot in legacy mode instead.
To me, this seems like a critical issue that the firmware *automatically* decides to overwrite the setting in the *bios*, without the user specifically requesting to do so.
I would think this is something that needs to be fixed in the IPMI spec.