From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030922
Description of problem:
While doing a kickstart installation (booting from CD, having the
ks.cfg on floppy and the installation tree available over FTP) I got
the error popping up:
Failed to log into 192.168.100.116
Failed to connect to FTP server
After pressing OK (possibly a coupple of times) it suddenly manages to
connect and then continues without problems.
Checking the network traffic at the time of the first popup reveals
that not a single FTP package has reached the FTP-server.
On Fedora Core 1, the installer discovers it has CD1 in the drive and
starts installing from there, so the problem doesn't surface.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. start a kickstart install using FTP
2. watch it stall
Created attachment 96156 [details]
Kickstart config used
Are you sure that you're not having network problems? There have been
no problems like that seen here or reported elsewhere.
What ftp server are you using?
I'm on a gigabit ethernet LAN and doing a manual install over ftp
The ftp server is a RHL 8.0 machine running wu-ftpd-2.6.2-12
Are you still seeing problems with this? Can you use ethereal/tcpdump
to watch the traffic on the network when it's failing?
Created attachment 98496 [details]
Yes, I can still se this problem with RHEL3 U1.
Here is a net dump done from a computer seeing the same traffic as the computer
I think the only interesting part of the conversation is at packet 929 where
the DHCP comversation takes place It's eventually successfull, but for some
reason the computer being installed does the DHCP dicsover twice...
And thats it from the computer being installed.
Guess worth noting is the fact that when I connect it to an old 100 MBit hub
instead of the Dell PowerConnect 5224 Gigabit switch it's normally connected
to, I cant reproduce the problem.
I also get exactly the same symptoms with Fedora Core 2: two
DHCPDISCOVER's, a DHCP ACK then nothing. The problem is not always
reproducible though; sometimes the next packet received is an ARP
(who has FTP.server.IP?) from the installation NIC and the install
proceeds normally. This also goes via a gigabit switch (Netgear
I'm curious what hardware you're running on. We are experiencing
similar problems with both NFS kickstarts (which was solved by bug
#110036) and HTTP kickstarts. Our hardware is the Dell PowerEdge
1750, which has a Broadcom BCM5704 NetXtreme dual gigabit ethernet
controller. The OS is RedHat Enterprise Workstation 3 update 2.
In our case, it doesn't matter whether we force the switch to 100Mbit
or use auto-negotiation; it takes nearly 20 seconds from the time the
interface is brought up until packets can actually be sent. This is
with Broadcom's bcm5700 driver; when using RedHat's tg3 driver, it
seems to take longer. When anaconda dynamically configures the
interface via DHCP, it does pause the full 20 seconds until the
transaction can be completed. However, it then brings up the
interface again (even though it was already up for DHCP), and the
connection to fetch the kickstart file times out after just a couple
I added some more error output to anaconda's urlinstStartTransfer()
function and got the following result:
Failed to retrieve /./kickstart/10.130.1.4-kickstart from 10.130.1.1:
Failed to connect to FTP server; No route to host
The fact that the program changes the url http://10.130.1.1/kickstart/
to http://10.130.1.1/./kickstart/10.130.1.4-kickstart is just a minor
annoyance, which Apache is able to correct (verified by telnet). But
can anybody explain why the system can't find a route from 10.130.1.4
to 10.130.1.1?!? (The netmask served by DHCP, BTW, is 16 bits.)
This very problem was reported fo a SuperMicro SuperServer 6012P-6 (
http://supermicro.com/products/system/1U/6012/SYS-6012P-6.cfm ) with
the Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev
0d) But I've seen this problem on systems with the dual Ethernet
controller: Broadcom Corporation NetXtreme BCM5702X Gigabit Ethernet
(rev 02) as well. In the latter case, the default tg3 driver is used.
This should be better in newer update releases of RHEL3.
I have seent his problem as well.