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
