Driver disk questions

[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

[Paul Howarth]

On Sun, 2006-08-06 at 18:35 -0500, Jay Cliburn wrote:
>  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.) 
For a driver disk to be recognized as such by anaconda, it needs far
more than the module itself to be present. You might take a look at the
Advansys driver disk I made to support installation of FC1, FC3, and
FC4:

http://www.city-fan.org/ftp/contrib/drivers/advansys/

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/

You'll probably need to boot in expert mode to prevent anaconda loading
the sata_via module before you get the chance to load your custom
module.

To answer your question, it'll be the .ko that you need.

If you were building for a 32-bit install, you'd need the i586 version
of the module for the installer, and the i686 version to the installed
system (if it was and i686 class processor). However, you're on x86_64,
which simplifies that.

>  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? 
Yes.

>  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. 
You could save yourself a lot of hassle by building the module as an
"out of tree" driver using the approach described in the release notes.

Paul.

[Jay Cliburn]

On Mon, Aug 07, 2006 at 08:38:28AM +0100, Paul Howarth wrote:
>  
>  For a driver disk to be recognized as such by anaconda, it needs far
>  more than the module itself to be present. You might take a look at the
>  Advansys driver disk I made to support installation of FC1, FC3, and
>  FC4:
>  
>  http://www.city-fan.org/ftp/contrib/drivers/advansys/ 
Thanks Paul.  I neglected to state in the OP that I had constructed the
requisite files into an image that was transferred to the floppy, but I 
was confused as to whether the .o or the .ko should be included in the 
modules.cgz file.  Some references on the web, and even a "build a driver
disk" script from Via Technologies, include only the .o file, and that
seems counterintuitive.  In the end, I included both.  (Still doesn't 
work, though.)  I also used your and Pasi's June 2006 exchange on 
fedora-list relating to this topic as one of my references.

>  
>  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.

>  You could save yourself a lot of hassle by building the module as an
>  "out of tree" driver using the approach described in the release notes. 
Yes, I tried doing that, but near as I can tell, the Makefile provided 
in the release notes assumes you're building a module against an installed 
kernel, which I'm not, and I couldn't quite figure out how to modify the 
Makefile to make it work for me.  What is the equivalent to KDIR in the
case where a module is built against a non-installed kernel?

obj-m := foo.o

KDIR  := /lib/modules/$(shell uname -r)/build
PWD   := $(shell pwd)

default:
	$(MAKE) -C $(KDIR) M=$(PWD) modules

Thank you,
Jay

[Pasi Kärkkäinen]

On Mon, Aug 07, 2006 at 08:00:47AM -0500, Jay Cliburn wrote:
>  On Mon, Aug 07, 2006 at 08:38:28AM +0100, Paul Howarth wrote:
>  > 
>  > For a driver disk to be recognized as such by anaconda, it needs far
>  > more than the module itself to be present. You might take a look at the
>  > Advansys driver disk I made to support installation of FC1, FC3, and
>  > FC4:
>  > 
>  > http://www.city-fan.org/ftp/contrib/drivers/advansys/
>  
>  Thanks Paul.  I neglected to state in the OP that I had constructed the
>  requisite files into an image that was transferred to the floppy, but I 
>  was confused as to whether the .o or the .ko should be included in the 
>  modules.cgz file.  Some references on the web, and even a "build a driver
>  disk" script from Via Technologies, include only the .o file, and that
>  seems counterintuitive.  In the end, I included both.  (Still doesn't 
>  work, though.)  I also used your and Pasi's June 2006 exchange on 
>  fedora-list relating to this topic as one of my references.
>   
Some links related to driver disks:

http://www.centos.org/modules/newbb/viewtopic.php?topic_id=3266&forum=29
http://forums.fedoraforum.org/showthread.php?t=113660

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195899


I've successfully built custom driver disk (floppy) images for RHEL4.x and CentOS
4.x, as you can figure out from the urls above.

But because of some unknown reason I can't get my driver disks working with FC5 or
FC6t1.. (see the bug above).

>  > 
>  > 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.
>  
Hmm.. I should try this too. 
 
-- Pasi
       
                                   ^
                                .     .
                                 Linux
                              /    -    \
                             Choice.of.the
                           .Next.Generation.

[Jay Cliburn]

Jay Cliburn wrote:
>  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(a)vger.kernel.org.

Thanks again for the tip, Paul.

Jay

[Paul Howarth]

On Mon, 2006-08-07 at 22:21 -0500, Jay Cliburn wrote:
>  Jay Cliburn wrote:
>  > 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. 
I think that the reason for this is that the updated module has not
actually been installed on the target system (this issue would not have
happened with a "real" driver disk btw). So the initrd used to boot the
system was made with the original modules, which don't work with your
hardware. You may be able to fix this by booting the rescue CD using
your custom module, copying your custom module on to the target system
in place of the original module, then rebuilding the initrd.

You will of course need to fix the initrd for any kernel updates you
install in the same way until your patch is included in a Fedora kernel
(via upstream).

Paul.

[Jay Cliburn]

Paul Howarth wrote:
>  On Mon, 2006-08-07 at 22:21 -0500, Jay Cliburn wrote:
> > Jay Cliburn wrote:
> >> 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.
>  
>  I think that the reason for this is that the updated module has not
>  actually been installed on the target system (this issue would not have
>  happened with a "real" driver disk btw). So the initrd used to boot the
>  system was made with the original modules, which don't work with your
>  hardware. You may be able to fix this by booting the rescue CD using
>  your custom module, copying your custom module on to the target system
>  in place of the original module, then rebuilding the initrd. 
1.  Booted linux-rescue
2.  modprobed libata and sata_via from floppy to recognize sata drive
3.  chroot /mnt/sysimage
4.  Copied libata.ko and sata_via.ko from floppy to /lib/modules/...
5.  Added "alias scsi_hostadapter sata_via" to modprobe.conf
6.  Executed the following in /boot
mkinitrd --preload=libata initrd-2.6.15-1.2054_FC5.img 2.6.15-1.2054_FC5
7.  Rebooted.

System now boots from HDD.

Thanks for your help.

[Matt Domsch]

On Sun, Aug 06, 2006 at 06:35:56PM -0500, Jay Cliburn wrote:
>  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.
>   
dkms can generate proper driver disks trivially.  dkms is in Extras.

-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com