Well, I've done quite a bit of testing to characterize this year-old problem when using Gbit ethernet interface cards. I believe the answer is somewhere in anaconda and is timing related. My next step is to load anaconda source and try to figure out how to fix this issue (I don't know anaconda nor python so that will be a slow process). This problem appears this has been in the discussion world for the past year now and is still a problem as evidenced by the number of responses I've seen to my first post. I'm pretty well convinced this is simply a timing issue and anaconda is declaring a failure too early. Perhaps someone with anaconda knowledge can point me in a direction that might help? My test effort / results to date: With considerable help from Richard Black, I've gone through modifying the initrd.img file to insert a script that loads the NIC driver then sleep for awhile before anaconda starts. The changes made to implement this idea work but they don't help - anaconda loads the driver again anyway. I then tried removing the entry for the e1000 driver for my card in the /modules/pcitable file in the initrd.img file. This didn't work since I then got a report that there was no network driver and the install terminated. Based on a suggesion by seph, I have experimented with connecting the pxe installation client to one of several different switch models. I found that some switches appear to work around the problem (Unfortunately I can't use any of the switches that do work around it - they are all 10/100). This does let me validate all of my setup and I know that the kickstart configuration is correct. After finding a switch that allowed a kickstart via network, I immediately ran into a bug reported earlier by Martin Robb (https://listman.redhat.com/archives/kickstart-list/2004-April/msg00107. html) and I cannot get Fedora Core 2 test 3 to finish a kickstart install (error installing at-3.1.8-52). Does anyone know of a fix for this yet? I was able to get Core 2 test 2 to run kickstart to completion. I tested the following switches and found some that worked and some that didn't. I tested with the kickstart file via NFS and HTTP and the installation files via NFS. Switches used when the kickstart install was successful (via network): Linksys EZXS16W 16 Port EtherFast 10/100 (Unmanaged) (HTTP ks failed once - tried again it worked) Intel InBusiness 16 Port 10/100 Switch (Unmanaged) Netgear FS108 8 Port 10/100 Switch (Unmanaged) Switches used when the install failed to get the kickstart file (NFS or HTTP): No switch (used crossover cable directly from pxe install server and client. The install server and client both use the same Gbit ethernet type) Netgear GS105 5 Port Gigabit Switch (Unmanaged) Netgear GS524T 24 Port Gigabit Switch (Unmanaged) 3COM 3C39036 36 Port 10/100 (Managed) Spanning Tree disabled Autonegotiate disabled Port set to 100half and 100full (separate tests) Note: Interactive installs work in all of these cases and I have no problems with the network once the installation is done. The only failure mode here is when anaconda loads the drivers and attempts to do an NFS or HTTP access for kickstart. I tried loading the kickstart file from floppy and the failure was simply delayed until it needed to access the NFS for the install files. A suggestion was made by lccha-rhlist@xxxxxxxx to update the e1000.ko NIC driver with the latest from Intel. I looked at their download site and their latest appears to be the same version that is in test 3. The Intel version is 5.2.39 and the Fedora Core 2 test 3 version is (reported when loaded by insmod) as 5.2.39-k2. I've been pulling my hair out on this one and really need to resolve it. I'm preparing to install a large number of machines using pxe installs and I don't want to have to do each one interactively. It would be great to get a fix for this in the Core 2 release. Thanks for any suggestions / help. Joe > -----Original Message----- > From: Ryan Golhar [mailto:ryangolhar@xxxxxxxxxxx] > Sent: Friday, May 07, 2004 8:08 PM > To: 'Discussion list about Kickstart' > Subject: RE: NFS kickstart fails with e1000.ko drivers > > > I observed the same thing with a Cisco switch. The switch > was set at 10 Mbps half-duplex. The fact that it was > obtaining a DHCP IP address threw me off for quite awhile. > > > -----Original Message----- > From: kickstart-list-bounces@xxxxxxxxxx > [mailto:kickstart-list-bounces@xxxxxxxxxx] On > Behalf Of seph > > Sent: Friday, May 07, 2004 10:12 PM > To: Discussion list about Kickstart > Subject: Re: NFS kickstart fails with e1000.ko drivers > > > > The switches I'm currently using are unmanaged netgear 24 > port (or 5 > > port) cheap switches so there is no way to change this. > > I've tried using a crossover cable so the switch was eliminated > > altogether - same results. I also tried using a 3COM 3C39036 > > 100 Mbit switch in default mode (I'll learn how - then try > > setting the portfast later to see if it helps.) > > I observed the same problem, and mentioned it here at the end > of march. unfortunately, I then got buried in work, and > didn't get a chance to debug it. > > I'd observed that kickstart failed for my dells with intel > gige on the motherboard. But only when hooked up to netgear > equipment. Failed on both a netgear gige switch, as well as a > netgear 10/100 hub. Worked okay on a cheap linksys switch though. > > I also observed the same failure. Namely, I could manually > walk through an install, but kickstart always failed to fetch > its config file. Interestingly, it successfully used dhcp to > get an ip address. > > I'm certainly interested in whatever results you end up with. > > seph > > > _______________________________________________ > Kickstart-list mailing list > Kickstart-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/kickst> art-list > > > > _______________________________________________ > > Kickstart-list mailing list > Kickstart-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/kickst> art-list >
