Cleanup of old firmware

[ITDEPT0014]

Upgraded to firmware 4.1.3(m) a few weeks ago and started to delete what was believed to be unreferenced firmware.

Deleted all old A and B firmware packages including ucs-catalog, and then noticed a few hundred major faults such as these below:

storage-controller image with vendor LSI Logic Symbios Logic, model SAS1064E PCI-Express Fusion-MPT SAS and version 01.32.09.00|06.34.00.00|03.22.00.00 is deleted
local-disk image with vendor SAMSUNG, model MZ6ER400HAGL-0K0 and version DM0V is deleted
TCA: etherNiErrStats crcDelta for sys/chassis-1/slot-2/fabric/port-2 , current-value = 799, raised above esc value 5

With the cause being "image-deleted"

After poking around I Changed Catalog Package Version to 4.1(3k)T believing this may help fix issue; it did not.

Looking at installed firmware, I do see the IO modules Backup version pointing to 3.2(3e), can this be the issue?

Attempted to re-download deleted firmware, and got a message "There is already another downloaded operation for the file" and references the b-series firmware that we attempted to download.

Does this mean some of UCS is still running on older firmware and the other is how to clear this up?

Are we at risk while system is in this state?

[Steven Tardy]

Often the "is deleted" is due to some Policy, like Host Firmware Package, many times the "default" HFP reference the version which was removed.

Can either:

1. Put the referenced version back by re-uploading that firmware bundle version to UCSM.
2. Changed the referenced version to the new version.
   (This may trigger a reboot of the server to push the new firmware.)
   (Most UCS deployments has this set to trigger the firmware on next boot instead of immediate, but sometimes it is not configured and may default to immediate reboot.)

The "backup" versions do not matter.
May have to delete old download requests. Just more non-obvious janitorial work.
There should be little risk, but having so many faults may prevent you from seeing a "real" fault which ought be addressed.

The "crcDelta" is usually either:

1. Upstream CRCs which get forwarded (due to cut-through switching) down to the chassis to (incorrectly IMO) trigger these faults.
2. MTU violations if Jumbo packets are getting truncated.

If the hardware is a 6200 Fabric Interconnect check the `connect nxos a` and `connect nxos b` command:

show hardware internal carmel crc

[ITDEPT0014]

Thank you Steven. We will review to see which path we take.  I'll update tomorrow on results.