Usually this works great-- boot from the SPP ISO, walk away for a beverage, come back and everything's updated. Not so on a few of my servers...

The final SPP release for these old DL360 G6 servers was Oct 2016, so that's what I'm using. Here's what I see during the automatic update process:

Deployment Log showing "no devices updated"

So far I've tried to update it from the OS (ESXi 5.5) using the downloaded standalone driver from HP (which has ESXi 5.5 listed as a supported OS) but that process fails with issues like:

# cd /tmp/usr/lib/x86_64-linux-gnu/hp-firmware-smartarray-14ef73e580-6.64-2
# ./hpsetup
./hpsetup: line 226: tr: not found
./hpsetup: line 226: tr: not found
./hpsetup: line 226: tr: not found
./hpsetup: line 226: tr: not found
./hpsetup: line 226: tr: not found
./hpsetup: line 293: syntax error: bad substitution

Running the raw .scexe has similar issues. Clearly a case of the OS not supporting the patch script.

I found this article which coincidentally has my identical starting firmware version (2.50) so I'm wondering if perhaps there's a bad version out there that breaks future automatic updates (fun!) https://bugs.centos.org/view.php?id=13184

Based on that, I plan to try and find a live CD that will work for this HP firmware update. Has anyone found one that works well for this process? Alternatively, is there a way to get the SPP update process to work correctly? (I would expect that boot environment to be VERY HP-firmware-update-friendly, yet in this case it seems to not work properly.)


I found something that worked on only the second try.

First try: system rescue CD

This fails due to fundamental kernel incompatibilities with the HP-provided binaries. That's not surprising since it uses a Linux kernel version 4 and the HP binaries are for version 2.

Second try: CentOS 6 rescue mode

This sort of worked. In order to make it work, I needed to copy the dirname and tr binaries from another preinstalled CentOS 6 server. There did not seem to be any way to add binaries to the rescue environment since it's mounted read-only as a loop device from an image in /tmp.

However, I could copy compatible binaries into /tmp and then add /tmp to my PATH.

On "centos6" existing host:

$ cd /tmp
$ <upload hp-firmware-smartarray-14ef73e580-6.64-2.x86_64.rpm here>
$ rpm2cpio hp-firmware-smartarray-14ef73e580-6.64-2.x86_64.rpm | cpio -id
31207 blocks

Here's what was done to make this work on the DL360G6 after booting CentOS6 into rescue mode, enabling network, and dropping to a rescue shell without attempting to mount any existing linux installations:

# scp user@centos6:/usr/bin/dirname /tmp/.
# scp user@centos6:/usr/bin/tr /tmp/.
# scp -rp user@centos6:/tmp/usr /tmp/.
# export PATH=$PATH:/tmp
# which tr
# cd /tmp/usr/lib/x86_64-linux-gnu/hp-firmware-smartarray-14ef73e580-6.64-2
# ./hpsetup

Magic! It works! CentOS 6 Rescue Mode as a Live CD with adjustments allowed update to work

Also confirmed from the ESXi 5.5 ssh CLI:

~ # esxcli hpssacli cmd --cmdopts="ctrl all show config detail"

Smart Array P410i in Slot 0 (Embedded)
  Bus Interface: PCI
  Slot: 0
  RAID 6 (ADG) Status: Disabled
  Controller Status: OK
  Hardware Revision: C
  Firmware Version: 6.64

Firmware Version: 6.64... nice!

  • 1
    I was able to get this working with Fedora 29 rescue mode quite easily. After running the rpm2cpio command on the file straight on my boot drive, I simply navigated to /run/install/repo/usr/lib/x86_64-linux-gnu/hp-firmware* and ran the hp setup from there. I did not require SCPing binaries or playing with PATH. – Shane Mar 19 '19 at 2:34
  • 1
    Thanks for trying that out! It's nice to know there's a compatible rescue environment out there which includes "tr" by default. – Steve Bonds Mar 19 '19 at 14:29
  • Yes it works. I had the same problem on the DL360 G7 P410i. After an unsuccessful update, I could not configure the raid at all! Thank. Instructions in Russian – Александр Рублев Sep 5 '19 at 19:02

I ran into a similar problem updating my HP Proliant DL380 G7 with a P410i raid card. Posting to help others.

When I ran hpsetup the error was "310: Bad Substitution"

My solution was to run ccissflash instead of hpsetup. It worked perfectly.

I did this under Linux Mint 20.1 x64 used firmware: Version: 6.64 (B)(1 Oct 2015) SUSE Linux Enterprise Server 11 (AMD64/EM64T) firmware-smartarray-14ef73e580-6.64-2.x86_64.rpm

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.