Adding the aforementioned device entries to the modules/pcitable and usr/share/hwdata/pcitable, and similar entries to usr/share/hwdata/pci.ids certainly helped. When I executed kudzu as follows: /mnt/sysimage/usr/sbin/kudzu -p the result included a correctly identified Intel Gigabit NIC, as follows: desc: "Intel Corp.| 82546EB Gigabit Ethernet Controller" This is certainly a direct result of the additions to the various PCI device tables. However, the e1000.o driver failed to load. I confirmed this by switching to VT3 and seeing an error message stating that the e1000.o driver load had failed. I suspect that the e1000.o driver that shipped with the RH7.3 anaconda does not support the Intel Gigabit NIC that I am trying to install, and this is why the driver fails to load. It seems logical that if the entries in the PCI device tables (pcitable & pci.ids) did not extend to the hardware version that I am using then so too the support offered by the e1000.o module may not extend to the newer hardware. This being said, I will definitely attempt to update the e1000.o module. In the mean time, I was only able to get a fleeting glimpse of the ?failed to load e1000? message on VT3 before it disappeared. How may I view, or redirect to a file or something, the messages that are piped to VT3 by the installer? May they be accessed from a file after the first reboot? Please help? Also regarding the RH8.0 version of the installer, is it possible to install RH7.3 with it, as I must install RH7.3 ? Regards, Matthew Richards Email: matthew.richards@xxxxxxxxxxxxxxxxxx >Now that my memory has been jogged, these changes must be made in stage1 - >yes, >I very well remember now!! I distinctly recall the 'magic' something or >other >message appearing on the blue transition screen as anaconda starts up, which > >is the transition to stage2. That said, I did the same thing you did :) >Went >after stage2 first! >When it worked, I think it was /tmp/modules.conf that had the e1000 entry in >it, as well as the module loaded. Yes, this is all quite clear now. I did >have to rebuild the relevant packages in stage1 - I believe it was >initrd.img >that contained the stuff? That part escapes me at the moment. >So basically, all of the device drivers (at least NIC drivers?) are detected >in stage1. I think I left my changes in stage2 as well, didn't hurt >anything. >And I also tried using the pcitable from the hwdata rpm if I recall >properly. >Just a little advice - look into the 8.0 stuff. It is really simple with >isolinux now. I have the proper cdrecord options too: >(code snippet) >system("/usr/bin/mkisofs -b isolinux/isolinux.bin -c isolinux/boot.cat >-no-emul-boot -boot-load-size 4 -boot-info-table -l -J -R -r -T -v -V >\'CDrom label\' -m \'*CVS*\' $cdburn_root | /usr/bin/cdrecord -v >speed=$config{burnspeed} dev=$config{dev} -"); >And my isolinux.cfg: >-------- >default linux >prompt 1 >display general.msg >label linux >kernel vmlinuz >append ks=floppy initrd=initrd.img lang= devfs=nomount ramdisk_size=9216 >label text >kernel vmlinuz >append initrd=initrd.img lang= text devfs=nomount ramdisk_size=9216 >-------- >I was very dissapointed to see that while the modification worked, it gave >me >that stupid error message about the bad magic number -- and users didn't >like >that too much, hence the transition -- and all of my installation woes went >away almost magically. >I have my comps file simplified down to something like the following: ><?xml version="1.0"?> ><!DOCTYPE comps PUBLIC "-//Red Hat, Inc.//DTD Comps info//EN" "comps.dtd"> ><comps> ><!-- <meta> --> ><!-- Meta information will go here eventually --> ><!-- </meta> --> >4 ><group> ><id>Base</id> ><name>Base</name> ><default>true</default> ><description>Required Base system packages</description> ><uservisible>false</uservisible> ><packagelist> ><packagereq type="mandatory">SysVinit</packagereq> >... ><packagereq type="mandatory">zlib</packagereq> ></packagelist> ></group> ></comps> >As you can see, very simple. Converted my old comps file with some >cut-n-paste >and some simple VI/VIM search and replaces, and was done. >At any rate, I hope this is helpful - look to stage1 to solve this issue >with >7.3, or convert to 8.0 and solve it altogether. >Let me know if I can help any more! >-brad >> >> Thanks for the advice Brad and Andrew. It certainly appears that the >system is not completely identifying the Intel Gigabit NIC during install. >> >> I followed your suggestion Brad, and added the extra device entries to the >pcitable file found in the modules directory of stage2.img. In desperation >I even added the extra device entries to the pcitable file in the modules >directory of the hdstg1.img file. It is worth noting that I took care to >correctly format the pcitable file with tabs (^I) and not spaces. >> >> However this appears to have not had any effect as the installer still >does not identify the device. If I switch to VT2 during the final stage of >the install and execute kudzu as follows: >> >> /mnt/sysimage/usr/sbin/kudzu -p >> >> the Intel Gigabit NIC may be found in the result. The output from kudzu >contains the following lines: >> >> desc: "Intel Corp.| unknown device 8086:1010" >> vendorId: 8086 >> deviceId: 1010 >> subVendorId: 8086 >> subDeviceId: 1011 >> >> I imagine that the device described above (Intel Gigabit NIC) should have >been successfully identified in accord with the changes that I made to the >pcitable file. However this does not seem to be the case, at least not >according to kudzu. >> >> I have located another pcitable file within the stage2.img and hdstg1.img >files under the usr/share/hwdata/ directory which I intend to update as you >suggested. >> >> I will also update the e1000.o module in the stage2.img file to version >4.4.19. >> >> Can anyone suggest why it appears that the Intel Gigabit NIC is not being >identified during install? Do I need to update pcitable elsewhere? >> >> >> Regards, >> Matthew Richards >> >> Email: matthew.richards@xxxxxxxxxxxxxxxxxx >> >> >> >> >> >I did precisely this and the limiting factor were the lack of entries in >the >> >pcitable - I don't think I had to replace any of the modules, only >update >> >the >> >pcitable to what the RH8.0 installer had: >> >> >0x8086 0x100e "e1000" "Intel Corp.|82540EM Gigabit Ethernet >Controller" >> >0x8086 0x100f "e1000" "Intel Corp.|82545EM Gigabit Ethernet >Controller" >> >0x8086 0x1010 "e1000" "Intel Corp.|82546EB Gigabit Ethernet >Controller" >> >0x8086 0x1011 "e1000" "Intel Corp.|82545EM Gigabit Ethernet >Controller" >> >0x8086 0x1012 "e1000" "Intel Corp.|82546EB Gigabit Ethernet >Controller" >> >> >That worked, but then I got some message about the magic number not >being >> >correct -- the install worked just fine, but that message was always >> >present. >> >> >Finally made the jump to 8.0 and have been fine since. The jump wasn't >as >> >bad >> >as I thought it would be, something you may wish to consider. The >biggest >> >challenge was the new comps format, however that can be quickly reduced >into >> >total simplicity too. >> >> >Try this: >> >> >kudzu -p >> >> >.... >> >class: NETWORK >> >bus: PCI >> >detached: 0 >> >device: eth >> >driver: 3c59x >> >desc: "3Com Corporation|3c980-TX 10/100baseTX NIC [Python-T]" >> >vendorId: 10b7 >> >deviceId: 9805 >> >subVendorId: 10f1 >> >subDeviceId: 2462 >> >pciType: 1 >> >.... >> >> >Notice the vendorId and deviceId. >> >> >27 @myhost:/home/bdoctor > grep Python pcitable >> >0x10b7 0x9805 "3c59x" "3Com Corporation|3c980-TX 10/100baseTX NIC >> >[Python-T]" >> >> >> >Good luck! >> >-brad >> >> >> >> Hello list, >> >> >> >> I am trying to get a Red Hat 7.3 based installer to detect and >configure >> >an Intel PRO/1000 NIC during install (the e1000.o module). >> >> >> >> Currently the NIC is not detected during install, but is found by >kudzu >> >after the first reboot. >> >> >> >> Upon extracting module-info, modules.dep, modules.cgz and pcitable >from >> >stage2.img i have found that it appears as though support for the NIC is >> >already included. I have drawn this conclusion after finding the >following: >> >> >> >> In modules.cgz: >> >> 2.4.18-3BOOT/e1000.o >> >> >> >> In module-info: >> >> e1000 >> >> eth >> >> "Intel EtherExpress/1000 gigabit" >> >> >> >> In pcitable: >> >> 0x8086 0x1000 "e1000" "Intel Corp.|82542 Gigabit Ethernet Controller" >> >> **and six more lines mapping similar device IDs to the e1000 module. >> >> >> >> I do not understand why the Intel gigabit card is not supported during >> >install. The only thing that I can think of is that the driver packed >into >> >modules.cgz does not work properly with the cards that I have tried. But >> >even that sounds a little strange!?! >> >> >> >> Could anyone please tell me if my assumption about e1000 support >already >> >being included in the installer is correct? >> >> >> >> Could anyone please tell me how I may update the e1000 module in the >> >installer? >> >> >> >> I have attempted a procedure similar to the one described at >> >>http://public.planetmirror.com/pub/ibiblio/docs/HOWTO//other-formats/html_ >s >> >ingle/KickStart-HOWTO.html#s9 with no success. Perhaps I got it worng. >> >> >> >> >> >> Thanks in advance. >> >> >> >> Regards, >> >> Matthew Richards >> >> >> >> Email: matthew.richards@xxxxxxxxxxxxxxxxxx >> >> >> >> >> >> >> >> _______________________________________________ >> >> Anaconda-devel-list mailing list >> >> Anaconda-devel-list@xxxxxxxxxx >> >> https://listman.redhat.com/mailman/listinfo/anaconda-devel-list >> >> >> >> >> >> _______________________________________________ >> Anaconda-devel-list mailing list >> Anaconda-devel-list@xxxxxxxxxx >> https://listman.redhat.com/mailman/listinfo/anaconda-devel-list >> >-- >Brad Doctor, CISSP