I manage a couple of hundred Linux servers, most of which are HP, if they are not virtualized. Historically, we have installed the HP ProLiant Support Pack (PSP) since before I started working here. The PSP comes with usefull (?) stuff like the HP System Management Homepage - which I have never used, but a couple of my colleagues do regularly - and a bunch of drivers.

Some of these drivers, like the iLO kernel module, are not in the stock kernel we use, so it might be useful to install those. Other drivers though, like the cciss and qla2xxx drivers HP supplies, aren't that useful: they are in the stock kernel and have been for quite some time. Overwriting the stock drivers will probably void support from our vendor on several kernel subsystems of not the whole kernel. On the other hand, HP might not support certain issues if you do not use their drivers.

I tend to lean to not installing the HP drivers, but what do you think: is there a tempting reason to install HPs cciss, qla2xxx, e1000, tg3, bnx2 (etc.) drivers and overwriting the drivers provided in the stock kernel package?

Edit: 'tempting reason to install' must be big enough to mitigate the disgusting quality of the packages of the PSP, meaning I have to repackage them all manually in order to be able to install through a centralized method like RH Satellite.

6 Answers 6


We have lots of Red Hat servers and have considered installing the PSP. The issue always comes down to the errata kernel support by HP versus what's current on Red Hat channels. We had the experience that the Red Hat version of the drivers was more up to date than the one provided by PSP. On another occasion the PSP limited us to a version of an errata kernel, which didn't make us very happy about it. Now, there been times where Red Hat didn't logged messages for issues with the hardware. Which is pretty bad on production servers, having servers go down or hang without any information or logs of the cause is not fun. At this point we have a hybrid, we've picked the packages that don't need an specific kernel version to work; like hp-health, hpacucli and the monitoring such. I think if HP/Red Hat and the rest are so tight, they should work together and include them on the Red Hat distribution. Is nonsense that there is even a support pack independent of the distribution itself.

  • I find this very interesting. I haven't come around to testing list (it's high on my list, but then so is a lot of other stuff): the monitoring stuff (hpsmh, the health stuff) works without requiring HP's ccsiss (et al.) drivers and such?
    – wzzrd
    Aug 10, 2009 at 21:10
  • Brilliant! We went with just installing hpacucli, hponcfg, hp-health and hp-snmp-agents and dropping the HP supplied modules. This way, we get a vendor supported kernel, properly monitored hardware and easy deployment and management of software (the HP supplied module packages are a real mess). hp-health etc. work fine with RHEL's native drivers. No need to install the PSP's mess instead. I tested the commandline tools (hpacucli, hpasmcli, etc.) and they work fine with the RHEL drivers too, meaning the snmp stuff will too. Thanks for this suggestion!
    – wzzrd
    Aug 31, 2009 at 8:59

We ALWAYS install the PSP with our HP machines - mainly to properly feed HP SIM with the right information. This allows SIM to centrally manage BIOS/driver code and importantly enables system-wide 'pre-failure' warning and hardware replacement. Specifically if a hardware component is about to fail it will alert us, raise a call directly with HP for the part and the man with a new bit pops up to replace it before it's even failed.

  • +1. Wzzrd didn't mention System Insight Manager, which is a big reason to install HP drivers.
    – kmarsh
    Jul 13, 2009 at 19:46

Vendor-agnostic answer.

You should contact the hardware vendor and ask them what the support reprecussions are if you install their drivers vs the OS drivers. Did you purchase the OS from them? Are they supported if they're not running Windows, Red Hat, SUSE, whatever?

Typically the value-add itself is just as you imply - additional server management features. Most often in my experience, these features are not that useful if you're automating your environment with something other than the vendor-supplied tools, or one of their affiliate brands (ie, IBM and Tivoli, HP and OpenView, etc).

For what it's worth, we automated the installation of the Dell 2950 remote console software that allowed connecting to the DRAC device via VNC, and the storage management GUI for the MD3000's. They're both recommended, and it was easier to automate than to explain to Dell "no we don't use that crap, we use what the OS comes with." Especially since we were using CentOS instead of Red Hat.


Here in the Windows world we find that Dell will not offer support unless you're using their drivers, and usually when you open a call the first thing they do is insist you install the very latest version of the drivers before they will touch the server. I don't know if this applies to Linux because I don't know what Linux support they offer, but I would check.


PS I don't think I have ever found the fault to be due to not using a Dell driver. Mind you I have never known the Dell drivers to cause a problem. Going along with Dell seems the path of least resistance :-)


First of all, HP servers are Red Hat and Suse certified, and you can get complete Red Hat support through HP anyway, so no worries about warranties either way there.

Second, power management is a big reason to install the latest drivers. If you have one server, maybe not a big deal, if you have several full blade chassis, big deal.

Third, as I commented above, HP System Insight Manager (or Dell OpenManage).

Fourth, if you have a Patch Management environment, and have to upgrade the patches within a certain period of time, tracking them through SIM really helps.


If you're using SIM, you should be able to push new drivers via that, instead of repackaging them (disclaimer: I know this works on Windows but I'm not a linux admin so YMMV). Also HP, like Dell, will always tell you to upgrade everything in sight before proceeding with a support case.

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.