Jay Cliburn
I built my kids a new computer for gaming: Asus M2V, AMD64x2, SATA HDD
(only), et al. I want to dual-boot XP and FC5.x86_64, but the SATA
controller for this motherboard isn't yet supported by the Linux kernel.
I have a one-line patch that adds the correct device ID to the
relevant kernel module, and I'd like to test it and submit it to
kernel.org if only I can get FC5 installed to test it. All I need to do
is replace the FC5 install sata_via driver with my own modified sata_via
driver. I've been wrestling all day with getting a suitable driver disk
(floppy) built, so far without success. I have a few questions.
First, some background:
* I'm doing the build work on an up-to-date rawhide x86_64 machine.
* I've installed kernel-2.6.15-1.2054_FC5.src.rpm in $HOME/rpmbuild.
* I'm building the desired module against kernel 2.6.15-1.2054_FC5.
1. The kernel module that needs to be modified is /scsi/sata_via.c.
I've built the kernel (mostly; see #4) and thus have the .o and .ko
objects for sata_via, but which one of those I should copy to the driver
disk image, the .o or the .ko? (I've tried both; neither worked,
although I see the driver in the driver picklist during the install.)
2. Is it okay to use the same driver name on the driver disk as the one
I'm trying to replace in the install kernel?
3. Is there some way to build a kernel rpm without having it "make
clean" right up front? If I encounter an error, I'd like the build to
pick up where it left off (at the failed source file), but "make rpm"
always wants to "make clean" and start all over. I issue the make
command from $HOME/rpmbuild/BUILD/kernel-2.6.15/linux-2.6.15.x86_64.
4. Can you tell me why this error is occurring? This is what happens
every time at about the 40-minute mark of the build process.
[...]
INSTALL sound/usb/snd-usb-audio.ko
INSTALL sound/usb/snd-usb-lib.ko
INSTALL sound/usb/usx2y/snd-usb-usx2y.ko
if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F
System.map -b /var/tmp/kernel-2.6.16rc6git3-root -r 2.6.15; fi
+ cp arch/x86_64/boot/bzImage
/var/tmp/kernel-2.6.16rc6git3-root/boot/vmlinuz-2.6.16-rc6-git3
+ cp System.map
/var/tmp/kernel-2.6.16rc6git3-root/boot/System.map-2.6.16-rc6-git3
+ cp .config /var/tmp/kernel-2.6.16rc6git3-root/boot/config-2.6.16-rc6-git3
+ /usr/lib/rpm/brp-compress
Processing files: kernel-2.6.16rc6git3-1
error: File not found:
/var/tmp/kernel-2.6.16rc6git3-root/lib/modules/2.6.16-rc6-git3
RPM build errors:
File not found:
/var/tmp/kernel-2.6.16rc6git3-root/lib/modules/2.6.16-rc6-git3
make[1]: *** [rpm] Error 1
make: *** [rpm] Error 2
Thanks,
Jay
不过,根据他说话的满口术语,也许他自己玩得更 high 一些,并且也许他在故意找茬,或者说在触动 redhat 某些人的某些敏感的地方。
update: 他的事情解决了
> On Mon, Aug 07, 2006 at 08:38:28AM +0100, Paul Howarth wrote:
>> However, it is possible to manually load the driver if all you have is
>> the .ko file. See for example:
>>
>>
http://www.keffective.com/mvsata/>
> Thanks for this. I ran across it early in my information search, but I
> didn't realize its significance until just now with your comment. I'll
> try this method this evening when I get home.
The method in the referenced link works, at least for me. I had to copy
libata.ko and sata_via.ko to a floppy, then follow the procedure in the
link and modprobe libata and sata_via from the floppy. This enabled the
kernel to see my sata drive long enough to install FC5. (Also tried it
with FC6T2 and it worked.)
Unfortunately, on the reboot following installation I encountered a
kernel panic very early on when /dev/VolGroup00 couldn't be found. This
happened for both FC5 and FC6T2.
At least, however, I was able to verify that my sata_via patch does in
fact cause the vt8237a controller to be recognized by the kernel, so I
submitted the patch to linux-scsi@vger.kernel.org.
Thanks again for the tip, Paul.
Jay