Infrastructure Software

well honestly - that's not quite the correct statement to make - HP is doing a very unfortunate thing here - they hardcode the exact kernel versions into the rpm. here are the problems you would encounter whether it is running rhel4 or el4

rhel4 42.0.8 is already released. according to the rpm textfile and the HP website, that's not even yet supported by the proliant pack. so if you ran rhel4 and ran with rhn and updated your system to have applied the latest kernel security update - it would fail because HP takes its time to validate their driver on the later kernels.

if you were a customer and ran into a bug that had to get fixed, whether you run rhel or el, you would get a kernel rpm back with a different version, one that would not yet be in that list.

so what it comes down to is that hardcoding versions into rpms like that is maybe useful for an initial install but is definitely not good for real world production environments.

we ARE working with HP to ensure they will be adding our kernel versioning to the checklist - however aside from that (and sorry if I am dissing HP a little bit here) - it's so restrictive that it doesn't help anyone. you have to be able to install bugfixes/updates when it's needed.

I will take a look at rpm and see if we can help you with a workaround to get this done. and I guess that would in fact also help rhel folks that would have similar issues.

Wim

Robert,

>
My question is this. Oracle Enterprise Linux is a branch of Red Hat. Is there work being done to make sure that Oracle's Linux flavor plays nicely with all of the major vendor's drivers?


Enterprise Linux is not a branch of Red Hat. We take the same source code that Red Hat uses and produce binaries based on that. The only thing we change are copyrighted or trademarked materials (think logos and text strings). After that we sometimes add bug fixes that Red Hat has not yet manage to fix but 1) are important enough to fix because they crash our customer's applications; and 2) they don't change the kernel application binary interface. With each package released from Red Hat at any time, we synchronize by starting the whole build process over, beginning with Red Hat's source. At each synchronization we make sure that we substitute fixes we made previously with Red Hat's fixes where appropriate. It's not a fork, nor a branch.

Sergio

Wim - I completely agree with your statement that the hard coding of the kernel versions in RPM are a bad idea. I am basically new with Linux (a two month newbie), so I was not sure how frequent this practice was. Just got worried when I was reading how Oracle Linux was going to utilize the RHEL naming scheme by marking Oracle's updates in the 4th/5th version entry. With an RPM like this, that naming scheme breaks. BTW - I am personally excited to see Oracle Linux and am anxious to see how much simpler Oracle can make the Linux installation and Oracle. I am liking how integrated HP is with their hardware and providing a good process to get Oracle RAC up and running VERY quickly. Impressed with HP, not so much with IBM since I can't find a similar commitment. Just my opinion and not my company's.

Sergio - Good point on the "branch" aspect of my comment. I know that that is one of the greatest fears with Oracle Linux and that Oracle is doing all it can to eliminate that mentality. When I mentioned "branch", I really meant that the kernel version stamp will be different from RHEL (for good reasons, like a kernel fix). This breaks those scripts that do string simple string comparisons.

I appreciate both of your replies.

Just to finish this thread. I was able to complete the installation of the "cpq_cciss" RPM once I had installed the latest kernel from ULN. The kernel I installed from ULN was 2.6.9-42.0.8.0.1.ELsmp.

The only thing I had to modify for the HP PSP to run successfully was that the /etc/redhat-release file to match a "red hat" version instead of Oracle's. Saw this as a workaround in several of the Validated Configurations on OTN.

I was using HP's PSP v7.70