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
>
