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
Note: If you are the author of this question and wish to assign points to any of the answers, please login first.For more information on assigning points ,click
here
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.
* 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 ...
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
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.....
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:
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?
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)
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.
Printable version
