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

Re: re[2]: adding e1000 module to installer

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">

<!--  <meta> -->
<!-- Meta information will go here eventually -->
<!--  </meta> -->


      <description>Required Base system packages</description>

	         <packagereq type="mandatory">SysVinit</packagereq>
		 <packagereq type="mandatory">zlib</packagereq>


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!

> 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 opensystems com au
>  >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 opensystems com au
>  >> 
>  >> 
>  >> 
>  >> _______________________________________________
>  >> Anaconda-devel-list mailing list
>  >> Anaconda-devel-list redhat com
>  >> https://listman.redhat.com/mailman/listinfo/anaconda-devel-list
>  >>
> _______________________________________________
> Anaconda-devel-list mailing list
> Anaconda-devel-list redhat com
> https://listman.redhat.com/mailman/listinfo/anaconda-devel-list

Brad Doctor, CISSP

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