Hello Chris, On Fri, 02 Nov 2007, Chris Arnold wrote: > I will not be able to run this command as of right now as this server > does not have an OS on it yet. I do know it is an american megaraid card > and dell uses it in the poweredge 4300 as a PERC2/SC. The firmware level > is at 3.13 for the RAID card. I can put SLES9 back on it and see what > this command produces?
wow! I never thought that somebody out there would have a similar or even the same problem like us at work. So let me start the story: The Dell PERC 2/3 RAID controller uses the exactly same kernel module like Dell CERC ATA/100 RAID controller, which would result in exactly the same problem we had. I had several interesting, but inoffical talks with people I know from being a Fedora maintainer at Dell and Red Hat and they told me, that the real vendor behind these cards (I think this was LSI Logic) and Dell decided to drop the support by their side around Linux kernel 2.6.9 and this explains for you, why a SLES9 (2.6.5-7.287.3) works - RHEL4 worked also but lost their support with U1 or finally U2. If you just call the technical support of Dell, they just know, it isn't supported and it doesn't work. They suggest you to use e.g. a old RHEL3 release or RHEL4 and avoid any updates...so nothing you want to use in a security sensitive environment. RHEL doesn't deliver the MPT legacy kernel module, SLES doesn't this if I remember correctly, too. This module didn't work for us anyway. Thus we grabbed the last known sources from the MPT kernel module and a colleague and I went to fix this module that it compiles on RHEL5 (x86_32), which has 2.6.18-8.1.15. Unfortunately several things in the Linux kernel changed and the pristine MPT kernel module from 2.6.9 didn't compile out of the box. At the end this module started working for us and we opened an internal RHEL5 repository available for the public use at http://repo.etes.de/rhel/5.0/. Let me say the whole thing was a time-consuming project but you now can install a RHEL (or CentOS) with one of this cards, add a URL for an updated installer image so that the installer works out of the box and after this simply add the repository URL and select our kernel module package so that the installed system even boots without manual interaction. So feel free to grab our source RPM containing the modified code and try to build the module on a working SLES10, put the module to a floppy and load it during installation. After installation you will have to put the module onto the installed system, too. Of course you will have to do such rebuilds of the module on every kernel update, this is why I decided to have a nice repository with RPM packages. The unfortunately thing in this case is, that you've got SLES and I absolutely can't help you how to play such tricks to the installer etc. as I did for RHEL. Oh and let me say...replacing a kernel module will conflict with your SuSE Linux Enterprise Server support contract (if any existing), same at Red Hat Enterprise Linux of course. Anyway I still hope, I clarified up many things for you and helped you at least a bit. Oh and this e-mail is absolutely no guerilla marketing from my side, we just decided to use RHEL internal for several different reasons. Greetings, Robert -- Robert Scheck Web: http://www.etes.de E-Mail: [EMAIL PROTECTED] ETES GmbH Libanonstrasse 58 A D-70184 Stuttgart Fon: +49 (7 11) 48 90 83 - 12 Fax: +49 (7 11) 48 90 83 - 50 Registergericht: Amtsgericht Stuttgart HRB 721182 Geschäftsführende Gesellschafter: Markus Espenhain und Jan Theofel Sitz der Gesellschaft: Stuttgart USt.-Id.Nr.: DE814767446 -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
