Thanks Ed. I too have come across a document similar to the one that you are referring to. It was posted to the Linux Managers mailing list. If anyone is interested in viewing it, it may be accessed via this URL: http://www.linuxmanagers.org/pipermail/linuxmanagers/2002-September/000731.html Regards, Matthew Richards Email: matthew.richards@xxxxxxxxxxxxxxxxxx >Matthew, >You are right, some cards require a newer version of the e1000 driver, >mine did. I compiled version 4.4.19 and included it in the initrd.img >(removing nfs and sunrpc modules to make room). If you'd like me to send >it to you, either the module or the initrd.img, reply directly. >You can find several references to compiling the driver with the right >kernel running and source installed, but the key I found in a letter to >some list, I'm not even sure it was this list, involved editing >/boot/kernel.h after you've booted the 2.4.18-3BOOT kernel, and >changing: >#define __BOOT_KERNEL_UP 1 >to: >#define __BOOT_KERNEL_UP 0 >and adding: >#ifndef __BOOT_KERNEL_BOOT >#define __BOOT_KERNEL_BOOT 1 >#endif >-Ed >On Fri, 2003-02-21 at 00:31, Matthew Richards wrote: >> >> 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 >> >> >> >> _______________________________________________ >> Anaconda-devel-list mailing list >> Anaconda-devel-list@xxxxxxxxxx >> https://listman.redhat.com/mailman/listinfo/anaconda-devel-list >>
