AdiF
Minnow
Posts: 15
|
Post by AdiF on Aug 1, 2023 15:03:25 GMT
When the bios patch the bootOrder in the system compute (which is the actual active boot order). What should happen to the boot order under the settings (the pending boot order). Should it be patch also to the settings also so pending and the active will be the same or should it remove the pending boot order so it will be empty.
Active:
POST https://${bmc}/redfish/v1/Systems/<system>/BootOptions
pending:
https://${bmc}/redfish/v1/Systems/<system>/Settings
"Boot": {
"BootOptions": {
"@odata.id": "/redfish/v1/Systems/Bluefield/BootOptions"
},
}
|
|
|
|
Post by mraineri on Aug 1, 2023 15:47:06 GMT
Can you actively change the live BootOrder without staging it first? I have not heard of systems with this capability; normally I'd expect that to mean you're actively setting UEFI variables at runtime to accomplish this.
Table 23 in the Redfish Specification has behavior dictated for how to represent the active resource and settings resource for different conditions based on what's allowed from a configuration perspective. You should review the "Writable, updates immediately or at a future point in time." row since the case you're describing is when you support PATCH for the property in both the active resource and the settings resource. However, I think it's worth reviewing the fact that you allow for the boot order to be changed on the fly without staging it for BIOS to consume on the next reboot; again, this is a capability I've not heard of any platform really supporting.
|
|
AdiF
Minnow
Posts: 15
|
Post by AdiF on Aug 2, 2023 5:40:15 GMT
Hi,
We are staging the bootOrder by using the settings. The user can only patch the settings, this will be staged and only after boot it will be apply. After applying, the UEFI patch the active boot order. When the UEFI applies this patch, should the bootOrder values in the settings also get patched to match the active bootOrder, or should they be cleared? This way, users would have clarity that their modified settings have indeed been implemented.
|
|
|
|
Post by mraineri on Aug 2, 2023 12:45:17 GMT
Got it, thanks for clarifying. Once the settings are applied on the next reboot, assuming everything is successful, I would expect the same values to be shown between the two resource. For example: - Initial state: the current boot order is Boot0001, Boot0002, Boot0003
- Active resource shows [ Boot0001, Boot0002, Boot0003 ]
- Settings resource shows [ Boot0001, Boot0002, Boot0003 ]
- User performs a PATCH on the settings resource to swap Boot0001 and Boot0002
- Active resource shows [ Boot0001, Boot0002, Boot0003 ]
- Settings resource shows [ Boot0002, Boot0001, Boot0003 ]
- User performs a system reset; new boot order is applied
- Active resource shows [ Boot0002, Boot0001, Boot0003 ]
- Settings resource shows [ Boot0002, Boot0001, Boot0003 ]
The other way to think about it is consider a subsequent reset; if the settings resource changes its values after the initial reset, then that means the new settings would be lost, which isn't desirable from the user's perspective. |
|
|
|
Post by mahantesh92 on Aug 2, 2023 18:18:04 GMT
If settings resource always holds the boot order, it may cause some conflicts.
For example, if a user changes the boot order from the BIOS menu or from the OS (i.e.., not via redfish) and reboots the system.
During the reboot process, BIOS redfish client fetches the settings resource and applies that order. Thus overriding the users change.
Is there a standard mechanism to prevent such a conflict/scenario ?
Thanks.
|
|
|
|
Post by mraineri on Aug 2, 2023 19:03:35 GMT
No standard mechanism; that's entirely left to the implementer to design how to keep the two coordinated. I certainly agree a designer needs to have that in place, but the standard doesn't dictate how you need to do it. Usually for BIOS-related items like this, BIOS tends to have a communication path with the BMC to send notifications like this so the BMC can update its view of the resource accordingly.
|
|
