Even though SLES 9.0sp4 is ancient (we are finally soon transitioning to the current version of SLES), we still need to be able to install it. Problem is that some new equipment we want to install it on are not compatible with the e1000 module but require the e1000e module. We need networking available during the install because the install works by pointing autoyast at a NFS-based repository which is where the install proper is done from. This autoyast installs both the base SLES 9.0sp4 system and our software on top of that.
This is what I've done to try to get the install boot to see the network:
- Done an disc-based install from the SLES 9.0sp4 on the new equipment.
- Downloaded the current e1000e module source from Intel and transferred it via USB stick to the machine.
- Build the e1000e.ko file and move it into place.
if-up eth0. Works fine.
So now I have a known working e1000e.ko file. I next did:
- Get a copy of our custom installed CD (the one that points to the autoyast stuff).
boot/loader/initrd, mount it via the loopback device, and copy the e1000e.ko file to
modules(which is a symlink to
- Unmount the image, recompress it, and rebuild our custom installed CD.
When I boot off the CD, the following happens:
- The installer kernel boots fine and makes it through all the usual preliminaries before trying to fire up the autoyast install.
- Installer errors out complaining it can't load e1000. (So apparently there's something somewhere that's telling it to load e1000 rather than going through and auto-detecting/auto-loading e1000e, or maybe an auto-load of e1000e is attempted and fails (see below))
- Installer drops into manual mode.
- I can use manual mode to "Load unknown modules" which shows the e1000e module as available.
- But when I try to load it it errors out with the following message:
e1000e: disagrees about version of symbol struct_module
I'm assuming (?) this is because the kernel that the install CD boots with (our custom install disc uses whatever's on the SLES 9.0sp4 install disc since we based it off that) is different than the kernel that actually gets installed onto the machine's hard drive (which is the kernel the module was built against)?
Is there any good way to deal with this? Any way to build the e1000e module so that it'll be compatible with whatever's on the install CD?
Or perhaps replace the install CD's kernel (where exactly does that live? In
boot\loader\linux ?) with the kernel from the machine I built the e1000e module on? Though if I do that I imagine I'll have to replace all the modules in the initrd with the modules from the machine or else I may have the same problem?
I guess one other possibility (perhaps the best one :) would be to find a USB ethernet adapter that is supported by whatever SLES9 kernel + modules the install CD uses and connect the network that way when doing the install.
I figured out how to generate a module the installer can use, though not yet how to get the installer to automatically use it.
The problem is that the installer kernel is
2.6.5-7.308-default but the kernel installed onto the machines is
2.6.5-7.308-smp. So on the machine where I built the module, I needed to install the
kernel-syms package and then instead of just
make in the e1000e source directory instead do
make -C /usr/src/linux-obj/i386/default M=$(pwd)
I then used the resulting e1000e.ko in the steps mentioned previously to build the CD and this time when it ultimately kicked me to manual mode the module loaded and the networking could be set up for the install.
Now the trick is to figure out how to make this module "known" to the installer so it'll just load and use it rather than kicking out to the manual mode.