> One note is that if the kernel being run isn't the same version as > the kernel installed in the chroot, kudzu will *not* > configure the device, > as it won't be able to find the module for it. > > Bill > So I tried both copying the running (boot cd) kernels modules directory to /lib/modules and making a symbolic link to the installed (on disk) modules directory (named with the running version) so that either way kudzu should be able to see the modules from either version. It still disabled this adapter. -- from earlier message -- > First, it checks that the IRQ in the PCI header isn't 0 or 255. That's > probably where it's bailing. from /proc/interrupts: 3: 236692 XT-PIC eth0 So this should be fine, its using irq 3 > Then it goes through the IO ports and memory for the device and > checks to see if they are marked disabled. > > Does it work outside of the chroot? Is /proc mounted inside the > chroot? At this point, I can't run it outside of chroot because libnewt isn't on this bootcd. If, in the chrooted environment, I mount /proc (it wasn't before), and copy the cds modules directory to /lib/modules (so both versions are there) it assigns the generic eepro100 driver to the device, and assigns the description "Unknown vendor|Generic eepro100 device". So this is certainly progress! I guess at this point I need to back up and explain why I'm doing this. The project I'm working on uses a custom boot cd, that, controlled by a central server, can either 1. install a machine with redhat 7.3 at startup, or 2. boot the installed redhat 7.3 (using kexec to load another kernel). If it installs the machine, we are using a modified version of anaconda to do so. Because of the custom bootcd, anaconda was removed from its typical environment and modified to run stand alone. This meant removing the RedHat program that normally creates /tmp/modules.conf with the loaded modules before install (also removed because our boot cd has its own mechanism to load modules). So, at the end of the install, we need to create a customized modules.conf for the machine. Currently, I am running kudzu in the chrooted env, and using the resultant hwconf to generate the modules.conf. This was the only mechanism I could find that _categorized_ the loaded modules, so I can create the eth, scsi-adapter, etc sections in modules.conf appropriately. Everything has been working ok until I ran across this network adapter. I think at this point I'll look through the kudzu source to see how it categorizes the modules, and use that instead of calling kudzu from a weird chrooted environment. Aaron _______________________________________________ Redhat-devel-list mailing list Redhat-devel-list@redhat.com https://listman.redhat.com/mailman/listinfo/redhat-devel-list
