PSP 7.7.0 and RHEL4U4

[Don Vanco - Linux Ninja]

After several years working for the dark (blue) side I am now back in the H-P fold.



I've tried on several system now (DL380G5s and now C-class Blades) to install the 7.7.0 release of the Proliant support pack, and have made several observations (and have a question) but they've pretty much failed and / or left me with broken systems

I'm referring to RHEL 4 Update 4 installs on both 32-bit and 64-bit machines. In all cases all current updates were applied, and this means the 2.6.9-42.0.10.EL kernels

1) The installer is looking for sym links in the modules tree that don't exist on ANY distribution.
Because I'm booted to an SMP kernel, the PSP installer is looking for links in /lib/modules/my_kernel-smp and of course they don't exist. My work-around was to simply create the sym links back to /usr/src/.... and while this appears to have "fooled" the installer, the resulting modules are junk regardless

2) It breaks networking & FC connectivity
It installs it's own bnx2, tg3, and lpfc drivers, and in the case of the bnx2 and tg3, it conveniently does NOT make backup copies of the original modules. So, when these broken modules don't work on reboot you are left with a system that will not connect to the network. Hope for your sake that you have the UP kernel installed or you'll be at the console forcing the SMP kernel back in
The FC driver gets backed up to ".orig"
TOTALLY irresponsible scripting to replace a stock module without backing it up - shame on you H-P....

Further, it makes ALL my NIC drivers bnx2 - when I am relatively certain that the on-board should be left as tg3

It also adds some mods to /etc/modprobe.conf for the LC cards that puke on restart, no doubt due to the bogus driver. Here again the original is thankfully saved off so recovery is not hard.....

3) The iLO hardware is never seen....
From what I can see the IPMI driver installs, but is NOT functioning (a slew of things fail when you start the service) - and I believe that without IPMI you cannot see the iLO2 hardware...

Again, it appears to the build not working as expected - I end up with a module, but my kernel does not like it:
[root@satellite init.d]# service hpasm start

Using high performance hp-OpenIPMI device driver
Starting hp-OpenIPMI:
insmod: error inserting '/opt/hp/hp-OpenIPMI/bin/2.6.9-42.0.10.ELsmp/ipmi_devintf.ko': -1 Invalid module format
hp-OpenIPMI: Not able to start ipmi_devintf.ko
[FAILED]



So, I can never get the PSP to install the iLO drivers and on-line config tools.

So my questions are -
Am I wasting my time trying to get this PSP to install?
Is it simply not supported on RHEL4U4?
(many systems do not appear to have support for this release but are already certified against RHEL 5??? Way to go H-P - chase the revision!)

How do I get IPMI functioning?

I refuse to use RHEL 5 until U1 is out. I worked on the beta before Red Hat took it behind closed door, and it was a pile. No way I'm suggesting it to my customers for some time. IMO H-P should have put the efforts into the current patches in RHEL 4.

Will I have better luck if I load RHEL4U3? The issues I reference make me think it's going to be as broken there as anywhere. I hate to go back that far, particularly since what I'm building is a 3-node GFS cluster and a Satellite server....

TIA
Don

[Don Vanco - Linux Ninja]

Anyone? No one uses RHEL 4 of the PSPs??

[Arthur Kao]

Just installed PSP7.70 on a fresh kickstarted Red Hat - BL20p G3.

cat /etc/redhat-release
Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
uname -r
2.6.9-42.0.10.ELsmp

No problem at all.
I do have this folder /lib/modules/2.6.9-42.0.10.ELsmp, though.

kernel* rpms I have:

kernel-smp-2.6.9-42.0.10.EL
kernel-smp-devel-2.6.9-42.0.10.EL
kernel-2.6.9-42.EL
kernel-ib-1.0-1
kernel-utils-2.4-13.1.83
kernel-devel-2.6.9-42.0.10.EL
kernel-2.6.9-42.0.10.EL
kernel-smp-2.6.9-42.EL
kernel-devel-2.6.9-42.EL
kernel-hugemem-devel-2.6.9-42.0.10.EL

[Steven E. Protter]

Shalom Don,

I support your RH5 decision.

I'd wait for update 2.

I'm mystified as to the issues. RH 4 update 4 with the .10 kernel is my most solid release combination.

I'm using yum to bring all my RH 4 systems to that level.

SEP

[Don Vanco - Linux Ninja]

While I appreciate the comment, that's an older Blade, and all of the hardware I've had failures on have been very new.

Just today I installed SLES9SP3 on some DL585G2s (10 Ethernet ports and 4 fibre ports each) and the install went smooth as silk. Unlike the RH installs there were far less dependency checks before compile.

I continue to be baffled.

[Fraser Campbell]

I have installed PSP 7.70 on 32bit RHEL4 Update 4 and had no issues. Granted I did not update from 2.6.9-42.ELsmp to 2.6.9-42.0.10.ELsmp yet.

I install with "./install770.sh -nui -silent".

On blade (BL460c) the system continues to use tg3 driver.

On DL585 G2 the system uses bnx2 driver but this is the same as Red Hat detects and uses on U4 IIRC.

On 64-bit there is an issue with hprsm that prevents some iLO communication, update to latest hprsm to solve this (http://h18007.www1.hp.com/support/files/server/us/download/26677.html).

I agree that the packaging is atrocious:

* overwriting Red Hat drivers is just silly, there should be a more elegant way
* update RH packages and the updated drivers are then broken (no dependencies get declared between HP's packages and the installed kernel)
* after installing a new kernel even if you try to rebuild a package before reboot it only looks at the running kernel instead of all available kernels so no rebuild is possible until after you've booted into new kernel

I've configured yum to keep all our RHEL boxes up to date, the HP packages make yum (or whatever you use) much more difficult.

I'm just beginning to investigate this myself, perhaps there's an elegant way to install and keep PSP up to date but I haven't found it yet ...

[Don Vanco - Linux Ninja]

Not so elegant, but I now tar up my modules dirs ;)

Don

[DanAm]

Hi,
so what is the story with this, I have exactly the same phenomena. So it works for some, and for some it does not ? Rather strange.
Anyone has an idea what's what ?
Best
Dan

[Don Vanco - Linux Ninja]

I've never seen anyone come up with a concrete answer, but in my own observations I seem to have more trouble when multiple kernels are installed. I really don't understand why this might be, but it's the only common thread.

I'm installing ICLE today on a couple c-Class chassis using RHEL 4 U3 (due to EMC iSCSI requirements) and I sure hope that it goes smoothly. I know that ICLE runs a dependency script to insure that the OS install gets the required packages for the PSP install/build, but I don't think it does more than that. If there's any significance to my results I'll post up.....

Don

[Don Vanco - Linux Ninja]

Follow up:
Blades ended up running RHEL4U5 and RHEL4U5.

On both Blades, the 7.7 PSP TG3 and BNX2 drivers were broken, and aliases in modprobe.conf were set incorrectly.

With the 7.8 PSP I am happy to report that modprobe.conf was not mis-configured, and both modules appear to function as expected.

[Ben Stokes]

Hello Don

I've been hunting around for answers for a few days as I have exactly this problem every time I install PSP 7.90 (the latest and greatest PSP) on HP DL380 G5's (I have 4 of them, all that exhibit this problem). I am using kernel 2.6.9-55.ELsmp and I don't have any other kernel installed ... the systems are vanilla just running RHEL 4 ES U5 and the following additional packages:

rpm-build
rpm-devel
compat-gcc-32
compat-gcc-32-c++
gcc gcc-c++
glibc libstdc++-devel
kernel-devel

I created the symlink to the kernel source in /lib/modules/`uname -r`/build like you, to stop the PSP installer from complaining.

I have found that if I use PSP to install everything apart from the ILO drivers, it works OK and I don't get this problem.

I was wondering if you found any way to repair or reverse the damage that PSP does? Or did you just rebuild your server and not use PSP to install the ILO drivers?

[Don Vanco - Linux Ninja]

Ben -
Nope. But I'll be the first to admit that I did not expend a huge effort to fix the PSP. I tend to simply capture the packages while they're being built by the PSP installer process, then take the steps I require to make them work across multiple machines.

This is in part because I don't want to try to fix the PSP for HP (and I cannot believe these get released into the wild without enough testing to pass muster on the most basic of installs like ours) but mostly due to the fact that I am "old school" Red Hat user and am used to dealing with RPMs and maintenance across multiple machines in my own way. The PSP is handy for sure, but I have my own methodology and tools that work just as well (if not faster). So, if it breaks on the first system I just compensate as required and get on with my life....

But when dealing with customer installs this is a PITA because the PSP really needs to work for them (and me) to make their lives easier.

I don't wonder if it's not simply the .55 kernel.....

On an interesting note - I did a RHEL5 install on Blades a couple weeks ago (both 32- and 64-bit) and 7.9 went in flawlessly; while pleased with the end result, it only adds to my confusion around RHEL4 behavior given that U4 is approaching "older than dirt" status (U6 in beta right now)

Don

[Steven E. Protter]

Shalom Don,

PSP 7.91 exists for a reason. There are big problems in other versins.

I have found subsequent releases of Red Hat are more stable than the previous releases.

Therefore I recommend you try update 5 and the latest PSP pack.

SEP

[Don Vanco - Linux Ninja]

Thanks Steven, but I am rarely master of my own destiny when it comes to OS / version selection. Case in point, RHEL4U4 was a requirement for HP/Oracle App Server based on statements from both at one point or another....

At any rate, I use (near) latest-n-greatest release when possible.