Actually the problem is NOT the net-bnx2 package, but the net-cnic package it depends on. Or to be more precise, it looks like a problem during the ESXi update procedure to interpret version numbers correctly.
You can see that if you check the esxupdate.log or manually try to update net-bnx2 it with the --update option:
# esxcli software vib update --vibname net-bnx2 --dry-run --depot /tmp/BCM-NetXtremeII-4.0-offline_bundle-1796156.zip
[DependencyError]
VIB Broadcom_bootbank_net-bnx2_2.2.5d.v55.2-1OEM.550.0.0.1331820 requires misc-cnic-register = 1.7a.02.v55.1-1OEM.550.0.0.1331820, but the requirement cannot be satisfied within the ImageProfile.
Please refer to the log file for more details.
So our net-bnx2 driver needs at least misc-cnic-register = 1.7a.02.v55.1-1OEM.550.0.0.1331820, but that package is in the bundle. Hm.
Next step, what net-cnic version do I currently have on my host?
# esxcli software vib list | grep -i net-cnic
net-cnic 1.72.52.v55.1-1vmw.550.0.0.1331820 VMware VMwareCertified 2013-11-21
Ok, we got 1.72.52.v55.1-1vmw.550.0.0.1331820 here. So the battle boils down to version string 1.7a vs. 1.72. Might be a bit ambiguous.
Now let's ask our ESXi host about what he assumes is the newer driver (make sure you scroll to the right to the Status column):
# esxcli software sources vib list -d /tmp/BCM-NetXtremeII-4.0-offline_bundle-1796156.zip
Name Version Vendor Creation Date Acceptance Level Status
------------------ ---------------------------------- -------- ------------- ---------------- ---------
net-cnic 1.7a.05.v55.3-1OEM.550.0.0.1331820 Broadcom 2014-03-04 VMwareCertified Downgrade
scsi-bnx2i 2.7a.03.v55.2-1OEM.550.0.0.1331820 Broadcom 2014-01-31 VMwareCertified Downgrade
net-bnx2x 1.7a.10.v55.1-1OEM.550.0.0.1331820 Broadcom 2014-03-04 VMwareCertified Downgrade
scsi-bnx2fc 1.7a.08.v55.1-1OEM.550.0.0.1331820 Broadcom 2014-04-17 VMwareCertified Downgrade
misc-cnic-register 1.7a.02.v55.1-1OEM.550.0.0.1331820 Broadcom 2013-12-21 VMwareCertified Downgrade
net-bnx2 2.2.5d.v55.2-1OEM.550.0.0.1331820 Broadcom 2014-03-27 VMwareCertified Update
Oops! All drivers contained in the bundle except net-bnx2 are actually being interpreted as version downgrades! Which is not quite correct though. The host doesn't see any need to update these packages with the --update switch
# esxcli software vib update --vibname net-cnic --dry-run -d /tmp/BCM-NetXtremeII-4.0-offline_bundle-1796156.zip
Installation Result
Message: Dryrun only, host not changed. The following installers will be applied: []
Reboot Required: false
VIBs Installed:
VIBs Removed:
VIBs Skipped: Broadcom_bootbank_net-cnic_1.7a.05.v55.3-1OEM.550.0.0.1331820
So what's basically happening causing these errors everybody has is:
- The host looks through the metadata version information and compares it with it's existing packages
- It assumes it can only update net-bnx2 while everything else is a downgrade, so only net-bnx2 is considered for the update process
- It checks the dependencies of the newer net-bnx2 driver, which say it needs at least net-cnic version 1.7a
- The host reverses the comparison approach it just did when it decided the other packages including net-cnic are downgrades, and thinks the existing net-cnic version 1.72 is too old to satisfy this requirement
- It throws an error that it can't update net-bnx2 (because of this dependency)
Apparently the ESXi updater gets confused by the ambiguous 1.7a vs 1.72 version strings conundrum. I don't know what's the general industry standard on versioning when it involves letters, so either VMware/Broadcom/HP messed up when naming these new versions or the ESXi updater is buggy when interpreting them.
So the best way to handle this issue currently is forcing the installation of the newer complete Broadcom bundle manually prior to the actual ESXi update with the --install switch like:
# esxcli software vib install -d /tmp/BCM-NetXtremeII-4.0-offline_bundle-1796156.zip
--
http://alpacapowered.wordpress.com
