Harry Putnam wrote:
Nikos Chantziaras <[EMAIL PROTECTED]> writes:
Harry Putnam wrote:
Nikos Chantziaras <[EMAIL PROTECTED]> writes:
[...]
mptbase: ioc0: Initiating bringup
ioc0: LSI53C1030 B0: Capabilities={Initiator}
scsi4 : ioc0: LSI53C1030 B0, FwRev=00000000h, Ports=1, MaxQ=128, IRQ=16
That's an LSI Fusion-MPT controller. Enable:
Device Drivers->[*] Fusion MPT device support->
<*> Fusion MPT ScsiHost drivers for SPI
Reboot. Have fun :P
I don't think thats the trouble... that has been enabled in every
kernel compile I've run trying to get a working config.
The original setup was rigged to boot with an initrd. How can I take
that initrd apart and see if there is some trick driver built into
it.
cp /boot/the-initrd-you-want ~/initrd.cpio.gz
gunzip ~/initrd.cpio.gz
Examine it's contents with mc or extract it with cpio.
But I don't think there's a "trick driver" or anything involved. You
don't even need an initrd if you compile the LSI driver in-kernel.
I just made in initrd for that kernel2.6.27-r5... and by god it
booted using the initrd so that initrd is loading the driver you
mentioned I guess.
I see now that even the original working kernel had LSI driver as
module ...so I'll try compiling into the kernel now as you've
suggested. Thanks...
You also need the filesystem driver built-in (ext3, Reiser, whatever
you're using.) An initrd is really only useful for generic kernels and
for bootsplash. I guess that means the appliance you downloaded was sub
optimal in the sense that nothing special or any kind of effort was
required to create it. A good appliance would have provided a slim
kernel with only what's needed compiled-in since VMWare has the same
hardware everywhere (that's the whole point of VMWare actually.)
