04-13-2011 12:20 AM
Is there a "correct" way to treat the PSP after kernel update, i.e. to build from-source modules against the new kernel?
I installed RHEL5u5 64 bit and applied PSP 8.43. After a yum update to a more current release, I now cannot mkinitrd (to update qla2xxx settings in initrd for multipath) because I get the following error: -
No module hpahcisr found for kernel 2.6.18-238.1.1.el5, aborting.
Modules that are built are as follows: -
Solved! Go to Solution.
04-13-2011 01:36 AM
The B110i is a software-based RAID controller that is upwardly compatible with "real" hardware-based SmartArray raid controllers. If your system contains a B110i controller, you should never update a kernel before checking that the kernel version is listed as supported in the Release Notes of the B110i driver. If it's not supported and there is no updated version of the B110i driver available yet, you must not install the kernel update.
You should now download the specific kernel version 2.6.18-238 from https://rhn.redhat.com (your RedHat Network password is required) and live with it until an updated version of the hpahcisr driver package becomes available.
HP provides the Proliant Support Pack and the hpahcisr driver in a yum-accessible repository format too. You can even mirror the repository to your organization's internal servers, if you wish:
See the "Getting Started" link at the left column for instructions.
----begin opinion piece----
I'm rather displeased that HP chose to use the SmartArray name with a software-based controller like B110i. I don't think it does anything good to the SmartArray brand name.
It would be better if HP provided hpahcisr driver updates for all (or most) errata kernels in a timely manner, but so far I'm afraid I can only describe HP's response to errata kernel releases as "slow and spotty".
At the moment, I would not recommend the B110i controller for new Linux implementations unless you know for sure the system is not going to require any updates.
----end opinion piece----
04-13-2011 04:39 AM
So to address my immediate concern, it appears I can use the --allow-missing switch to mkinitrd to update my initrd.
Curious why that modules been installed (not sure if it's been loaded, got to do some more testing) by PSP though, since it wouldn't have detected any matching hardware. I guess hpsum /s isn't quite as intelligent as it should be.
So the remaining query is whether or not there is anything to do generally for PSP post kernel update. I know for example that the hp-ilo module gets recompiled by /etc/init.d/hp-ilo if a module doesn't exist for the currently booting kernel, but I don't know what the rest do - looks like they just get moved to "weak-updates"?
I'm going to have a play building a box and applying PSP before and after patching and see what differences there appear to be, but any further insight into best practice approach would be appreciated (apart from don't install newer kernels than the PSP release notes say :D)
10-15-2012 10:10 AM
[root@xyz]# rpm -qp --scripts kmod-hpahcisr-1.2.6-13.rhel5u8.x86_64.rpm
postinstall scriptlet (using /bin/sh):
if [ -e "/boot/System.map-2.6.18-308.el5" ]; then
/sbin/depmod -aeF "/boot/System.map-2.6.18-308.el5" "2.6.18-308.el5" > /dev/null || :
## GMM - Added hpahcisr to PREMODS variable in
## /etc/sysconfig/mkinitrd/hpahcisr used by mkinitrd.
## Puts hpahcisr at the top of the driver load order in initrd.
echo "PREMODS='hpahcisr '" > /etc/sysconfig/mkinitrd/hpahcisr
chmod 755 /etc/sysconfig/mkinitrd/hpahcisr
Comment this line you will not see the error . Apparently removing the rpm does not remove this file.
[root@raptor-bk ~]# cat /etc/sysconfig/mkinitrd/hpahcisr
# PREMODS='hpahcisr '
12-07-2013 07:38 AM
Thanks!!! adding --allow-missing to the mkinitrd worked for me.......saturday morning patching. Last thing I need is something that is going to slow me down like a kernel panic