dell / iDRAC-Redfish-Scripting

Python and PowerShell scripting for Dell EMC PowerEdge iDRAC REST API with DMTF Redfish
GNU General Public License v2.0
603 stars 279 forks source link

ComponentID zero #276

Closed rowlap closed 8 months ago

rowlap commented 9 months ago

80 talks about the Redfish FirmwareInventory endpoint, but I'm seeing ComponentID 0 for a small but significant percentage of devices.

As predicted, following a manual firmware update, the Network device gained a ComponentID.

Is this the only way to populate ComponentID? It would be useful for surveys and update planning, but is frustrating due to the partial coverage.

texroemer commented 9 months ago

Hi @rowlap

You're correct, when a device reports component ID as 0 this means either the device has never performed a firmware update or the payload image stored for the device in iDRAC memory was erased.

When a firmware update is performed, iDRAC is able to get the component ID from the Dell Update Package (DUP) payload and update the property value. It will also copy the payload from the DUP to iDRAC memory which this stored payload can be used to rollback the device firmware if needed. If the user runs SystemErase feature to wipe LC data, this process will wipe the payload stored in iDRAC memory and iDRAC will no longer have the component ID info, report a value of 0.

Thanks Tex

rowlap commented 8 months ago

Hi @texroemer, thanks for the update.

I had thought ComponentID was some internal namespace where the iDRAC mapped a certain PCI vendor:device ID, rather than provided by the DUP package.

This creates a bootstrapping problem where we can't apply a DUP via automation because we haven't first applied a DUP. Given the limited number of devices (NICs, mainly) I can create an external mapping from IdentityInfoValue, but now have a problem where new servers arrive with ComponentID=0 but up-to-date firmware.

In this case do we need to apply the DUP of the already-installed firmware, just to populate ComponentID?

texroemer commented 8 months ago

That's correct, if you have a device which is reporting 0 for Component ID you'll need to perform firmware update for that device, either flash to same, old or new version to update the component ID.

Also all servers from the factory should have component ID reported in firmware inventory for all devices and you should never see 0.

Thanks Tex

rowlap commented 8 months ago

Also all servers from the factory should have component ID reported in firmware inventory for all devices and you should never see 0.

Unfortunately this is not what we see by a long stretch.

Let's close this issue now, as we understand what ComponentID=0 means and what to do about it.

My thoughts are something like a device name -> firmware URL mapping in a curated list which we'll have to hand-maintain, but shouldn't have too much churn once it's up and running.

texroemer commented 8 months ago

Sounds good but can you share what iDRAC version came on the server from the factory where you saw 0 for component ID and also what component(s) reported 0? This information will help me with escalating this issue back to iDRAC/factory teams.

Thanks Tex

rowlap commented 7 months ago

Looking at an example recent (February) system it's using iDRAC 7.00.60.00, reporting ComponentID 0 for NIC and "PCIe SSD" i.e. NVMe drives. On other systems it can be BOSS / PERC components.

Not to overstate the problem but we see a significant volume of these on new purchases. As a workaround we're looking at falling back to the PCI IDs.

Happy to share more details outside of a public github issue.