Bug 110843 - kickstart install fails to connect to FTP server
Summary: kickstart install fails to connect to FTP server
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: anaconda   
(Show other bugs)
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-11-24 20:10 UTC by David Juran
Modified: 2007-11-30 22:06 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-18 14:37:43 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Kickstart config used (9.09 KB, text/plain)
2003-11-24 20:11 UTC, David Juran
no flags Details
dump (107.93 KB, application/octet-stream)
2004-03-12 17:33 UTC, David Juran
no flags Details

Description David Juran 2003-11-24 20:10:22 UTC
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
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):

How reproducible:

Steps to Reproduce:
1. start a kickstart install using FTP
2. watch it stall


Additional info:

Comment 1 David Juran 2003-11-24 20:11:42 UTC
Created attachment 96156 [details]
Kickstart config used

Comment 2 Jeremy Katz 2003-11-24 22:23:39 UTC
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?

Comment 3 David Juran 2003-11-25 15:53:41 UTC
I'm on a gigabit ethernet LAN and doing a manual install over ftp
works fine.
The ftp server is a RHL 8.0 machine running wu-ftpd-2.6.2-12

Comment 4 Jeremy Katz 2004-02-12 16:25:12 UTC
Are you still seeing problems with this?  Can you use ethereal/tcpdump
to watch the traffic on the network when it's failing?

Comment 5 David Juran 2004-03-12 17:33:12 UTC
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
being installed.
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.

Comment 6 Simon 2004-07-08 11:54:13 UTC
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 

Comment 7 Trevin Beattie 2004-07-08 20:49:55 UTC
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
of seconds.

I added some more error output to anaconda's urlinstStartTransfer()
function and got the following result:
   Failed to retrieve /./kickstart/ from
   Failed to connect to FTP server; No route to host

The fact that the program changes the url
to 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
to!?  (The netmask served by DHCP, BTW, is 16 bits.)

Comment 8 David Juran 2004-07-14 08:35:06 UTC
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.

Comment 9 Jeremy Katz 2004-10-18 14:37:43 UTC
This should be better in newer update releases of RHEL3.

Comment 10 jacob liberman 2005-02-28 21:17:37 UTC
I have seent his problem as well.

Note You need to log in before you can comment on or make changes to this bug.