Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

While BMC is updating image, firmware inventory will generate redundant ID #13

Open
urieliyahu opened this issue Jul 11, 2023 · 4 comments

Comments

@urieliyahu
Copy link

urieliyahu commented Jul 11, 2023

Issue:
Redundant values returned by Redfish GET request from /redfish/v1/UpdateService/FirmwareInventory

Description:
The Redfish GET request from /redfish/v1/UpdateService/FirmwareInventory is returning redundant values. This issue seems to be related to the phosphor-bmc-code-mgmt functionality.

During a BMC firmware update, a new object is created that includes the xyz.openbmc_project.Software.Version interface. This interface plays a crucial role in listing all the firmware inventory using the Redfish GET request.

However, when performing a firmware update and calling the GET request, the result list includes the new BMC firmware object, even though it should not be part of the firmware inventory list since the image is not yet active.

Related Code:

This issue is not BMCWEB issue , seems to me that the the fix should be at the phosphor-bmc-code-mgmt.

Redfish output Example:
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory",
"@odata.type": "#SoftwareInventoryCollection.SoftwareInventoryCollection",
"Members": [
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/bd850aa9" (This is the running BMC)
},
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/e2960819" (The new BMC FW, not running )
}
],
"[email protected]": 2,
"Name": "Software Inventory Collection"
}
Questions:

  1. Is this issue already known?
  2. What are your suggestions for an acceptable fix?
@mine260309
Copy link
Contributor

Is this issue already known?

I think it's a known behavior, bmcweb will get all the firmware from the DBus.

What are your suggestions for an acceptable fix?

What do you suggest to handle this case?

@ueliyahu
Copy link

FW update, can be spited to three steps

  1. Before: copy the image to /tmp/images.
  2. During: update in process (RequestedActivation already set to Active)
  3. After: FW update completed

The following table compare the properties Activation and RequestedActivation for current FW and new FW .
(busctl introspect xyz.openbmc_project.Software.BMC.Updater /xyz/openbmc_project/software/)

image

So as you can see , if RequestedActivation=None and Activation=Active that it is necessarily the current FW.

base on that, my suggestion is to add better filtering to bmcweb code.
https://github.com/openbmc/bmcweb/blob/609ba4c9ffb9c6b83861ff557108c89007ca369a/redfish-core/lib/update_service.hpp#L862

Does it reasonable solution ?

@mine260309
Copy link
Contributor

I think it depends on Redfish to define "what the FirmwareInventory should contain", should it contain the active ones only, or it should contain the uploaded ones?
Could you initiate a discussion in the mailing list?

@ueliyahu
Copy link

Hi,
From redfish documentation I can't conclude it
image
However for projects that use PLDM instead of updater , we get only the active FW as result.

Not sure about the mailing list, where I can find it ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants