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
