Bug 119173 - FTP install fails with "Unable to retrieve stage2.img"
Summary: FTP install fails with "Unable to retrieve stage2.img"
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda   
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2004-03-25 22:24 UTC by Andrew
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

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

Attachments (Terms of Use)
Text output from FTP session packet capture (18.23 KB, text/plain)
2004-03-26 12:16 UTC, Andrew
no flags Details
Text output, FTP packet capture (14.03 KB, text/plain)
2004-03-26 13:00 UTC, Andrew
no flags Details

Description Andrew 2004-03-25 22:24:08 UTC
Description of problem:

FTP install fails with

Unable to retrieve

Version-Release number of selected component (if applicable):
Fedora Core 2 Development up to FTP available 25 March, 2004.

How reproducible:
99.9% of the time.

Steps to Reproduce:
1.  Start Fedora installer from bootable CD with "linux askmethod"
2.  Select FTP install method, DHCP
3.  Enter IP address for servername (e.g.
4.  Enter directory (e.g. fedora)
Actual results:
Unable to retrieve...

Expected results:
Retrieves files from FTP and starts X installation.

Additional info:

Firstly, no matter what you do the installer inserts the "/" in front
of the directory name.  And if you try with no directory, anaconda
tells you that you must have a directory in the directory field.

Secondly, I'm using an ip address for the server name.  Based on the
logs from /var/log/vsftpd.log, it seems that the installer is not
actually transferring any files, although Alt+F3 shows:

* trying to mount CD device hdc
* transferring to a fd
* transferring to a fd
* transferring to a fd
* transferring to a fd
* 248044 kb are available
* transferring to a fd
* transferring to a fd

Somehow, *I think*, disabling the firewall this morning ("service
vsftpd stop") allowed this to work.  But I was also using
anaconda-9.91-4 and anaconda-runtime-9.91-4 this morning.  Error this
morning was when it was installing the RPMs - complained that it
couldn't find fedora-release-1.91-6, so I updated the appropriate
files and re-burned the DVD (actually, recreated the *.iso; that's
what's mounted on the FTP site at with
anaconda*9.91-6...still no luck.

Changed /etc/hosts.allow with ALL: ALL and restarted xinetd and
vsftpd, but that didn't help either.

Comment 1 Andrew 2004-03-25 22:32:32 UTC
Note: disabled the firewall with "service iptables stop", then did
"service vsftpd restart"   (Oops.)

Comment 2 Andrew 2004-03-26 12:16:08 UTC
Created attachment 98880 [details]
Text output from FTP session packet capture

OK, more info.

Tried using a false directory on the FTP server just to see what the response
was...same info on the tty on Alt+F3 (* 248044 kb are available).

I'm attaching the packet capture from the FTP session.	x.x.x.254 is the FTP
server, and x.x.x.252 is the FTP client.  Both are on the same subnet, subnet
mask is  By the time it gets to "stage2.img", this strange
error starts appearing (FTP server tells client):

Response: vsf_sysutil_recv_peek: no data

Additionally, I created a new directory under /var/ftp and mounted the DVD
image there.  Then I logged on as a user in anaconda ("use Non-Anonymous FTP"
checkbox) and provided path: /var/ftp/andrew (absolute path, not an FTP virtual
root), username: andrew, password: xxxxx to the installer and it worked.
However, *anonymous* still fails during install.  Perhaps this is due to the
virtual root?

Comment 3 Andrew 2004-03-26 13:00:47 UTC
Created attachment 98881 [details]
Text output, FTP packet capture

Well, somewhere between yesterday afternoon (see previous attachment# 98880 [details])
and this morning it seems to have stopped working.

As I recall, I had mounted the DVD (not the iso image) at the FTP path,
manually set the IP and removed the default gateway and primary dns settings,
then I set the server, directory, username and password and it worked.	Using
the same stuff, it isn't working today.

Interestingly, I'm now seeing ICMP Destination Unreachable messages (Ethereal):

Type: 3 (Destination Unreachable)
Code: 10 (Host administratively prohibited)

Comment 4 Andrew 2004-03-26 13:16:13 UTC
And after info posted here:
about ICMP reject code 10 "administratively prohibited", I disabled
the firewall ("service iptables stop").

Anonymous FTP still fails, but user "andrew" worked.

Comment 5 Jeremy Katz 2004-03-27 20:32:10 UTC
This sounds like your ftp server is misconfigured.

Comment 6 Bret Gutt 2005-01-27 01:10:39 UTC
Note that I saw similar problems. For my setup, I was installing Fedora Core 3 
onto "machine1" which had a CDROM drive in it, with the intent of pulling the 
rest of the installation media using the FTP method using "machine2" as the FTP 
server. I had burned the boot.iso onto a CDRW and it booted fine into 
machine1.  I specified the IP address of "machine2" which is on the LAN (no 
intervening firewall hardware, and iptables on machine2 was set up to allow ftp 
from the LAN only).  "machine2" was running Red Hat 7.3 and the wu-ftpd daemon 
was running.  The installer complained with the message:

Unable to retrieve

I ran ethereal on machine2 and watched the FTP protocol which showed:

220 machine2 FTP server (Version wu-2.6.2-5) ready.
USER someuser
331 Password required for someuser.
PASS ***
230 User someuser logged in.  Access restrictions apply.
200 Type set to I.
227 Entering Passive Mode (192,168,0,3,119,206)
RETR /scratch1/overflow/someuser/raw/linux/FedoraCore3/alldiscs/Fedora/base/upda
550 /scratch1/overflow/someuser/raw/linux/FedoraCore3/alldiscs/Fedora/base/updat
es.img: No such file or directory.
221 You could at least say goodbye.

I was puzzled by that since the error message stated a path to "stage2.img" and 
not "update.img".  I tried doing an "ftp localhost" from machine2 and verified 
that I could not cd into /scratch1, so my wu-ftpd (or something else) must be 
(mis)configured to disallow me to cd into /scratch1.

My fix was to just move my "alldiscs" directory into the someuser HOME 
directory, and everything proceeded from there.

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