How to configure RDP to install latest Support Pack

[David Stephens_1]

We installed RDP several months ago, and at that time the current Proliant Support Pack was version 6.40. Now that v7.0.0 is available, we would like to install that when we roll out new blades. I can't find the specific procedure to accomplish this. I did find one hit in the knowledge base on setting up a distribution job to push out new support packs to running servers, but I'm trying to save a step.

[Bill Lane]

David,

I think what you need to creat a new directory structure under 'Deployment Server\Deploy\CDS\Compaq' for your new support pack. Then you just need to copy the appropriate CP######.exe & bp######.* files into them.

Once set up you will need to make your deploy jobs point to the new directory rather than the old one!

[David Stephens_1]

I should have provided more info. I did, indeed, set up a separate directory for Support Pack v7.0.0 (deploy\cds\compaq\ss.700\w2k\ntscp) and copied the Support Pack files into that folder. This follows the setup for version 6.40. I've also copied the default W2K install script, and changed the 3rd 'Run Script' task, specifying SET SS=SS.700. When I boot a blade, it performs the Initial Deployment phase, but when I drop the new script on it, it runs through the first couple of steps in the install script but fails somewhere in the format disk phase. (The error refers to there being 'no bootable partition.') This is very hard to debug because the messages scroll by too fast to see what is failing. It actually appears that the failure occurs BEFORE the process gets to the phase where I've specified the new location for Support Pack.
If anyone can point me to the documentation for this process, I'd be eternally grateful!

[Bill Lane]

David,

This sounds very much like an issue I have as well were it is not doing some of the steps but reporting them as done. I have a question out in this forum but have had no answeres yet! :(

[Ed Cox]

David and Bill,
Some random thoughts,
It seems to me that if the parition is not available so that the OS files can be copied to it...then the problem most likely lies with the array controller setup. If the array setup goes ok, then the cpqfmt.exe file kicks in and formats the partition. If the array is not setup properly then cpqfmt.exe can't format the partition and that's why you get that message.
What is the name of the .ini file you are using to setup the array hardware in your script? Also take a look at the contents of that file for any errors. And make sure the filenames follow the 8.3 DOS naming convention.
I hope this helps...
Ed Cox

[Bill Lane]

Ed,
Certainly in my case it some times does the array bit but then does not put a logical disk on it, others it puts the LD on but does not format it - all a bit random! :(

All that said when I was doing some more testing the other day it was all working fine.........

[David Stephens_1]

In my case, I think I've got the problem narrowed (?) down to this: the directory structure of the support pack files. The original support pack v6.40 has these subfolders under W2K folder: $1, NTCSP, and TEXTMODE. The support pack files seem to be in the NTCSP folder, and the other two folders contain various driver files - but I don't know the origin of those other files. I created only the NTCSP folder in my new ss.700 directory, and copied all of the v7.00 support pack files there. My scripted install job now functions OK up to the point where the driver files are to be copied, but since I don't have the other folders/files, I am getting 'missing file' errors in the copy phase. I've scanned every PDF I can find, trying to dope out this setup, but I'm drawing blanks.

[Ed Cox]

David,
Strictly as a test...but try this...
Copy over the 6.40 $1 and Textmode directories to the W2k area where you created the ss.700 folder. Basically duplicating the structure there as well. See if that works.
Those $1 and Textmode folders were put there during the installation of RDP (the Proliant Integration Module portion of the install). However you can tell that just by creating a new PSP folder (i.e. ss.700), it's not enough.
The unattend.txt file checks it's own local set of drivers in the body of it's file (i.e. [Mass Storage Drivers]section and compares that with the drivers listed in the txtsetup.oem file. If there is a driver listed in the unattend.txt that doesn't match the txtsetup.oem set of drivers, or if unattend.txt can't find the txtsetup file in your case...then the process bombs out.
Let me know what you find out...
Ed