pschaff wrote:
The "dd=" parameter is to specify a "driver disk" for the installer to load. It has nothing to do with the "dd" command, nor creating a new ISO image.

marty_one wrote:
Quote:

pschaff wrote:
The "dd=" parameter is to specify a "driver disk" for the installer to load. It has nothing to do with the "dd" command, nor creating a new ISO image.

Im sorry but this does not solve the problem i am faced with. With the types of systems I deal with, sometimes I wont have physical access to these system to build. I have to do it through iLO (hardware based remote access to the server).

marty_one wrote:
...the only solution I can see that will work is to re-author the iso image of CentOS 5.3 to inlcude [sic] the raid controller driver...

BTW you still haven't answered the 'fakeraid' question, which i think is the real issue here : i doubt such embedded controller is a real raid adapter, and i even think that it's only based on the ICH10 chipset. When you boot the installer, do you see two independant volumes ? If so , forget about that fakeraid configuration and use linux software raid instead

You don't need physical access to that system for the dd= parameter to work (see http://www.centos.org/docs/5/html/5.2/Installation_Guide/ch-bootopts-x86.html)

<snip>
[ ] modules.cgz 06-Nov-2009 19:33 399K
<snip>

To be honest im not sure about what you mean by real raid/fake raid as there is a built in hardware controller for it. I might agree with you that it might be a fake raid as in the past with these systems, the raid controller that came with them I not only had to create the raid config but build the array as well. With these new ones you create the raid config but you dont build the array!

arrfab wrote:

When you don't specifiy dd= (and so don't use a driver disk), what are you able to see in the disk partitioning step ? No disks at all or two separate volumes ? If so that confirms that it's a "fakeraid", meaning a mix of proprietary software driver to simulate a raid1 controller (and that uses ~10% of cpu just for the IOs).
Let's answer first that part ..

AlanJBartlett wrote:
Something to try.

Quote:

<snip>
[ ] modules.cgz 06-Nov-2009 19:33 399K
<snip>

The modules.cgz file contains the driver module. It's a gzip'ed cpio archive, so you could extract the .ko file from it and attempt to use it . . . ?

marty_one wrote:
If the driver is not loaded when the boot loader starts, the installer finds two seperate disks sda/sdb. In the older server you have to build the array with the bios utilities. With the newer one you just create the raid config and thats it, no build option, nothing. Even with the kick start software that HP include (which is able to talk to the raid controller) doesnt have an option to build the array. So i'm going to say (based on your descriptions) that it is a fakeraid array.

arrfab wrote:

Okay so now we're sure that it's a fakeraid. Don't even try to load a proprietary binary driver that "emulates" a raid1 and do that directly within Linux with software raid (with mdadm). You'll save yourself time and pains : the problem with such driver (that taints the kernel) is that they are tied to a specific kernel version and so cause you pain when you want to just update your kernel. That problem doesn't occur of course with linux software raid. I've seen also that it's better/faster on the IO level to use the included software raid than a proprietary solution (I migrated two small servers for a customer who wanted to use the proprietary driver and those machines were suffering during work time : iowait , while they were reinstalled using simple linux software raid and work like a charm now)