I followed your suggestions (The makefile uses only uname -m, -a, and -r options):

[root@localhost ~]# /bin/uname.orig -m
i686
[root@localhost ~]# /bin/uname.orig -a
Linux localhost.localdomain 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:55:12 EDT 2007 i686 i686 i386 GNU/Linux
[root@localhost ~]# uname -m
i586
[root@localhost ~]# uname -a
Linux localhost.localdomain 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:55:12 EDT 2007 i586 i586 i386 GNU/Linux
[root@localhost ~]#

And after I compiled my module:
[root@localhost src]# strings e1000e.ko | grep verm
vermagic=2.6.23.1-42.fc8 SMP mod_unload 686 4KSTACKS

The vermagic is still 686… I think that I would need to compile the e1000e module against the 586 kernel sources.

Thanks for your help.

If you want the module to load cleanly during the kickstart, you need to make sure that the output of uname -a is the same on both the PXE system and the compile system. The last time i had to make this happen, i just temporarily replaced the uname binary on the compile system with a shell script that spit out the string i wanted, compiled the module, then put the proper uname back. A little bit hacky, but it only took 30 seconds, and it worked like a charm.

As for passing options to your module, if you still need to, i’d suggest taking a look at the “device” keyword in kickstart :
http://fedoraproject.org/wiki/Anaconda/Kickstart#device

(p.s. Sorry for the late reply – it’s vacation season around these parts. :) )

The work I am doing involves a PXE booting attempt of an old Fedora release, Fedora 8, on a relatively new Intel hardware. I used a trick to make the PXE booting work that shed some more light onto a possible difficulty I described to you earlier.

I plugged a USB to Ethernet adaptor to the new hardware while still having an Ethernet cable plugged into the Ethernet card and tried to boot the system up. The Ethernet card did dhcp request and got its IP and PXE info. The USB driver got preloaded and took over the Ethernet card to finish the OS installation and booting.

Now, I changed my kickstart file and added in the post section compiling & installing of the e1000e module and got a more readable error this time:

e1000e: version magic ’2.6.23.1-42.fc8 SMP mod_unload 686 4KSTACKS’
should be ’2.6.23.1-42.fc8 SMP mod_unload 586 4KSTACKS’

suggesting an 32 vs 64 bits incompatibility. However, when installing the very same driver after an initial boot, I do not get this error any more. This suggests that some difference between the kickstart environment vs post kickstart root environment that knows how to handle 64 bit targeted modules (I think).

I can still force install the e1000e from the kickstart file by issuing “modprobe -f e1000e” and that seems to work OK. Which brings to my question to you. The method that you describe uses some implicit way to pre load the module: you define alias and pci.id translation and when kernel sees this PCI it attempts to load the module. However, there seems to be no way to specify the details of *how* to load the module to include module settings or maybe, as it is in my case, to force the module loading. Do you know if there is a way to specify that?

Thanks

The first thing that comes to mind is that you may have built the module against a different kernel than that used by the network boot image. If you did a “yum update” on the build machine, for example, you are definitely using a different kernel…

Great article!

I followed your steps pretty closely trying to update the e1000e NIC driver in the modules.cgz file (there was one there but obsolete) and added my NIC card device ID to modules.alias and pci.ids (the e1000e does not depend of other module similarly to e1000).

I got the driver from the same box after I installed fedora 8 on it manually, build the driver, installed it, and tested.

When I try to boot of the network with the new initrd.img, it fails to insert the e1000e module with following message:
…
warning: failed to insert module (8)
Error : failed to insert /tmp/e1000e.ko
…

Would you know what it means and what possibly could be wrong or how to get more meaningful error indication?

Thanks

Thanks!

clayzer :
Excellent leads for me. Thank you both!
Turned out to get the from header (I use postfix) I needed to type:
mail -s “testing” to@example.com ~h
FROM: from@example.com ^D
CC: ^D

Turned out to get the from header (I use postfix) I needed to type:
mail -s “testing” ~h
FROM: ^D
CC: ^D