This page describes the steps necessary in order to cast ndiswrapper inside of an iso/system chroot.
Define/export USE_KERNEL_VERSION and get_kernel_version will return it. -lynx
This requires a bit of trickery. The spell sets KVERS against the currently running kernel version, because normally this would be the required case (casting ndiswrapper on a normal system). However, this is problematic if the iso kernel happens to be different from the kernel running on the development machine. This was the case for me when modifying the devel iso (I am running 2.6.23.12, the iso has 2.6.22, specifically 2.6.22-SMGL-iso). Here is what I did to work around this problem.
Note that I compiled/installed the kernel in the chroot manually, and you will likely not be affected by this problem if you install the kernel via cast -r linux, as the definition of get_kernel_version checks a sorcery-tracked kernel version before looking up the "running" kernel version.
Inside of the system chroot:
edit /var/lib/sorcery/codex/stable/kernels/ndiswrapper/BUILD
- make KVERS=$(get_kernel_version)
+ make KVERS=2.6.22-SMGL-iso
edit /var/lib/sorcery/codex/stable/kernels/ndiswrapper/INSTALL
- make KVERS=$(get_kernel_version) mandir=${INSTALL_ROOT}/usr/share/man install &&
+ make KVERS=2.6.22-SMGL-iso mandir=${INSTALL_ROOT}/usr/share/man install &&Of course, replace "2.6.22-SMGL-iso" with whatever the actual kernel version inside the chroot is. Also, in case this isn't yet clear, you will need to have the kernel sources (for header files) as well as the /lib/modules/KVERS/build dir available.
Once you finish casting ndiswrapper, don't forget to change the settings back to the originals (this is really more important for the system chroot atm, but will be important for the iso chroot later as we shy away from having a separate system tarball). If you forget to change it back, this could have consequences for the user later if they install their own kernel and boot to that before setting up networking with ndiswrapper.