re[4]: adding e1000 module to installer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux