Openbmc: IPMI get boot options - unexpected results

[dkodihal]

I tried the following on openbmc master commit a415413, from the host :

a) set boot option to cdrom
ipmitool chassis bootdev cdrom

b) read it back
ipmitool chassis bootparam get 5
Reads back as expected (cdrom)

c) set boot option to bios
ipmitool chassis bootdev bios

d) read it back
ipmitool chassis bootparam get 5
Reads back as cdrom and not bios, that's the bug.

[dkodihal]

I sent some details about this to the community :

In the IPMI spec the boot device selector has options for both "boot source" (default/disk/crdom/network) and "boot mode" (default/bios/safe/diag). Since this isn't a bit-filed, you can't override for eg both the source and mode at the same time. It's probably debatable to say whether such a possibility is desirable or not (for eg I may want to set the boot source as network by default, but want to boot to safe mode the next boot , and revert back to network for subsequent boots without having to set the device again).

There are different D-Bus interfaces depicting the boot mode [1] and boot source [2] though. So when the IPMI boot device is changed, the ipmid code sets a relevant boot mode or source property. It's possible that both can get set when someone for eg sets the device to cdrom and then to bios. The issue is how should ipmid respond to a get boot options command - there's no way for ipmid to aggregate information from both D-Bus properties as in the IPMI spec only one of them can be represented. Today ipmid always favors the boot source property if both are set [3]. That's not what a user expects though, because the user would expect his last override to go through.

The solution I'm proposing is that if a set boot device is mapping to a boot source, then reset the boot mode D-Bus property to default, or vice versa. This way the ipmid code can determine which property is not at the default value. It doesn't break the behavior from an IPMI spec perspective because only one can be set at a point of time anyway, and we'll consume the latest override to the boot device. Other solutions or thoughts?

[1] https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Control/Boot/Mode.interface.yaml
[2] https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Control/Boot/Source.interface.yaml
[3] https://github.com/openbmc/phosphor-host-ipmid/blob/master/chassishandler.cpp#L1257

[gkeishin]

Thanks, @dkodihal will look into the test code as well.

    Run IPMI command  0x0 0x8 0x05 0x80 0x18 0x00 0x00 0x00

    ${boot_mode}=  Read Attribute  ${CONTROL_HOST_URI}/boot/one_time  BootMode
    Should Be Equal As Strings  ${boot_mode}  ${BOOT_MODE_SETUP}

    ${output}=  Run IPMI Standard Command  chassis bootparam get 5
    Should Contain  ${output}  Force Boot into BIOS Setup

This should have caught this one.. weird stuff, checking the test into details

[dkodihal]

@gkeishin note that you need to successively set a "boot source" and then a "boot mode".

[rfrandse]

https://gerrit.openbmc-project.xyz/10479 Fix get boot options returning unexpected results
Resolves #3067 IPMI get boot options - unexpected results