HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
BladeSystem - General
cancel
Showing results for 
Search instead for 
Did you mean: 

Virtual Connect 'error in package'

 
Aaron.S
Frequent Advisor

Virtual Connect 'error in package'

I'm trying to update the firmware for my VC from 2.10 to 2.12 on a c7000 enclosure.

But for both the 2.10 and 2.12 firmware packages I get the error message 'error in package' after it tries to load it.

The 2.10 package is the exact same file I used to originally update it to 2.10 (same location in the file system etc.)

I've tried redownloading both files and checking their MD5.

A new HP 4GB VC-FC Module is also in the enclosure. Its firmware version is reporting as 1.11, where as the other VC-FC is reporting as 1.32.

What could be the cause of this error?
3 REPLIES
marcus1234
Honored Contributor

Re: Virtual Connect 'error in package'

reboot oa then reinsert each interconnect what happens now
marcus1234
Honored Contributor

Re: Virtual Connect 'error in package'

hmm from a previous post by the Brit cudos to




This thread describes a problem and provides a solution. It doesn't require any responses (unless you feel the need).

The problem was that upgrading VC using VCSU and "vcfwe1f230.bin" failed to complete the upgrade on 4 x HP 4Gb VC-FC Modules installed in bays 5, 6, 7, and 8. The modules were previously at version 1.32, and the upgrade was to bring them to 1.40.

During the upgrade process, VCSU indicated that the firmware package had been uploaded to the FC modules and the activation phase was attempted on all modules. No error messages were generated, all that was displayed was a message indicating that the upgrade had failed on all of the FC modules.

Playing a hunch, and based on the fact that the F/W upload appeared to have succeeded, I tried cycling the power (via software) on one of the modules. This did not appear to have any affect on the F/W version as displayed in the OA screens.
The second approach was to physically remove the module and then replace it. This caused several things to happen.

1. The remove/replace was recorded in the SYSTEM Log.
2. The module was no longer displayed on the "Interconnect Bays" screen, and remained absent for ~3-4 minutes.
3. When the module reappeared, it showed up with the new F/W, i.e. Version 1.4.

After performing this procedure on all of the delinquent modules, they all showed in the OA screens as being at FW version 1.4. In the VCM Firmware Management screen however, only some of them displayed the new firmware (note:, before cycling the modules, none of them were indicating a firmware level as installed/running).

(Note: this clearly implies that a software power cycle IS NOT equivalent to a remove/replace of a module.)

To try and clear this up, I failed over the VCManager, which made all of the modules look the same, i.e. the FW version disappeared from all of the modules in VCM (go figure!).

Anyway, the OA still confirmed that all VC FC modules were running version 1.40, so I quit while I was ahead.

While I am a big fan of Virtual Connect, and HP's blade systems generally, I would be so much happier if they were a bit more robust. I find it very disconcerting when programs produce different outcomes, in virtually identical conditions (no pun intended).
Terri Harris
Honored Contributor

Re: Virtual Connect 'error in package'

Aaron,

Are you using the VCM GUI or the VCSU (VC Support Utility) to update your modules? (Also are you aware there is a 2.31/1.40 revision now?).
I would focus on just flashing the one VC-FC module that is currently showing 1.11 first so all the VC modules have matching firmware.
It is sometimes necessary to physically reseat an interconnect module, including a VC module. Normally this is only necessary one timeand NOT every time you need to update.
A good maintenance procedure that does not cause any production interruption is to physically reseat both OA modules (if you have 2) and the OA tray that the OA module is in installed in. This can be done with everything powered up. Just be warned that the enclosure fans will all kick up to 100% when and while there is no OA module to access.