Add an option to disable boot source override

[Kostr]

Currently there is no simple command in ipmitool that can be used to disable boot source override feature.

Boot source override enable is controlled via boot flags valid bit:

You can query its current value with a chassis bootparam get 5 call:

$ ipmitool <...> chassis bootparam get 5
Boot parameter version: 1
Boot parameter 5 is valid/unlocked
Boot parameter data: e000000000
 Boot Flags :
   - Boot Flag Valid                                       <-----------
   - Options apply to all future boots
   - BIOS EFI boot
   - Boot Device Selector : No override
   - BIOS verbosity : System Default
   - Console Redirection control : Console redirection occurs per BIOS configuration setting (default)
   - BIOS Mux Control Override : BIOS uses recommended setting of the mux at the end of POST

But there is no easy way to clear this bit with ipmitool, besides ipmitool raw command.

One might argue that ipmitool chassis bootdev none should give you the desired result, but that is not true for x86. As an example compare these two overrides:

 Boot Flags :
   - Boot Flag Valid
   - Options apply to all future boots
   - BIOS EFI boot
   - Boot Device Selector : No override

 Boot Flags :
   - Boot Flag Valid
   - Options apply to all future boots
   - BIOS PC Compatible (legacy) boot
   - Boot Device Selector : No override

In these cases even if we don't override boot source, we override boot mode (Legacy/EFI) which can be undesired behavior.

Is it possible to add a command to ipmitool for boot flag invalidation? Perhaps something like this:

ipmitool chassis bootdev invalidate

[Kostr]

One more observation:

$ ipmitool chassis bootdev none options=help
Legal options settings are:
  help                  : print this message
  valid                 : Boot flags valid
  persistent            : Changes are persistent for all future boots
  efiboot               : Extensible Firmware Interface Boot (EFI)
  ...

From this help message it looks like the boot flags valid bit should only be set if options=valid is passed. But from my observations each of these commands set the boot flags valid bit:

ipmitool chassis bootdev none
ipmitool chassis bootdev none options=valid

I might be wrong but it looks like the valid bit is set unconditionally in ipmi_chassis_set_bootdev:

static int
ipmi_chassis_set_bootdev(struct ipmi_intf * intf, char * arg, uint8_t *iflags)
{
        ...
	/* set flag valid bit */
	flags[0] |= 0x80;
        ...
}

https://github.com/ipmitool/ipmitool/blob/d674bfdc9a2447706ea9b0b943c98bcb0bbe80d2/lib/ipmi_chassis.c#L1321

[doublechiang]

I am interested in what's the scenario to use this command, can you give me an example about what condition you will use this command? Also, the boot priority command will be invalid if the 'power cycle' is not issued within 1 minute. I think this behavior reduces the chance that you need this command.

[Kostr]

@doublechiang can you say to me, what part of IPMI are you talking about, when you say boot priority command will be invalid if the 'power cycle' is not issued within 1 minute ? I'm working on the OpenBMC project (https://github.com/openbmc/openbmc) and I don't beleive that it has such functionality present.

[doublechiang]

In the IPMI specification 2.0. released in 2013. Section 28.12. Set system boot options command.

[AlexanderAmelkin]

In the IPMI specification 2.0. released in 2013. Section 28.12. Set system boot options command.

Actually this is not always true because there is also this (see bit 3):

Also I'm not sure that OpenBMC currently honors either section 28.12 or that bit.

[Kostr]

@doublechiang ok, thanks for the information, I've missed this part in the spec. But as @AlexanderAmelkin have pointed, this timeout behaviour is optional. In other cases we might actually need to manually perform boot flag invalidation. Also I don't really understand how this timeout should work with a persistent override. Shouldn't boot flags always be valid in this case?

[doublechiang]

As far as I know, the boot priority command (without persistent) overrides the boot priority once, next boot it will use the original setting. With the persistent flag, once you issued a power cycle command after the boot priority command, it will last forever until you have an AC power cycle, or, there is a manual setup (for example, you choose to enter the BIOS setup menu).

[Kostr]

@doublechiang in this case isn't a persistent override an example of a case where we might actually need to have the ability to invalidate boot flags manually? So we could fallback to the original boot priority setting that is stored in BIOS.

[doublechiang]

Thanks for sharing the scenario. IMHO, it's rare to use the persistent flag already, and there is no such case to invalidate the previous command, just issue another boot priority to whatever you like to boot from and it works well for me. But that's only my opinion, not representing the majority.