Red Hat Bugzilla – Bug 113471
Cannot connect to HTTP(FTP) server in network install
Last modified: 2007-11-30 17:10:35 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.2.1)
Description of problem:
I cannot connect the HTTP(FTP) server during network installation
of x86_64 version of Fedora.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
I have tried to install x86_64 version of Fedora to my PC.
I got server name and directory before installation.
I tried two servers: mirrors.kernel.org(18.104.22.168),
In installation, according to instruction,
I wrote the name and directory path as follows:
Then I got following Error:
"Unable to retrieve
When I changed the server, results was the same.
Well, I notice the following:
The number of / between 120 and fedora in error message should
be only one.
So I guess it is a bug of fedora installer.
Hmmm, Justin reported taht it worked for him. I haven't noticed
problems in the past either. Try adding a / to the beginning of hte
path and see if that works?
This bug is with the development tree. It does not seem to be an issue
in the FC1 preview or the existing FC1 work.
I have added the / at the head of the path in installtion.
But the status remains unchanged.
I have been giving up the installtion by network...
I finally have been able to connect to HTTP
server(mirrors.kernel.org) in network installation.
And I guess the reason of unconnectivity is
a configuration of the server.
Because the success occurred when I changed the
configuration of PC to connect the Internet directly.
Originally I have used the PC in home LAN, in other words,
I have connected to the Internet through firewall,
and tried to install Fedora.
When I installed the x86_64 version of SuSE by network,
I could connect to the SuSE installation server from home LAN.
Anyway, I have not completed the installation since
I have encountered the another problem.
In installation, after setting time zone,
I get following messages:
Now I feel the installation of development tree
is so painful and unusable :-(
You're trying to install the *development* tree. The fact that it's
broken sometimes should be expected. If you want something that's
just going to work, use the FC1 test release instead of the
I think this should be happier with recent changes in CVS
This problem still exists. I have a http server running on my home
network. The box I'm trying to install Fedora on just has a floppy
drive and a network card.
On my http server, I created a simple directory called /fedora that
contains all the Fedora files. I verified that this does work
correctly by pointing another browser on the network to
http://192.168.2.2/fedora and getting the contents of that
directory. As overkill, I went to
http://192.168.2.2/fedora/Fedora/base/stage2.img to verify that it
was being served by the http server, which it was.
However, on the box that I'm installing Fedora on, I'm told to
perform my http setup. Under "Web site name", I put "192.168.2.2",
and under "Red Hat Directory", I put "fedora". When I select OK, I
get an error that says, "Unable to retrieve
http://192.168.2.2//fedora/Fedora/base/stage2.img" (notice the extra
slash between the IP Address and the directory). To add insult, when
I click ok at the error message, it sends me back to the http setup,
where the "Red Hat Directory" line has replaced "fedora"
I think this bug still exists, and should be reopened and fixed.
Some more information on this bug.
The reason why this bug may not be noticed all the time is because it
seems that Apache will ignore two slashes next to each other, and
interpret it as one, so even though the Fedora installer is requesting
"http://192.168.2.2//fedora..." from the web server, the server is
saying, "ok, I know what you meant..." and sending
"http://192.168.2.2/fedora..." This same instance also happens later
when installing the RPMs. Looking through the log during the install,
I noticed that the installing is always requesting
"http://192.168.2.2/fedora//Fedora/RPMS/...", but Apache is smart
enough to know what the requester meant.
This is still a bug and should be fixed... we can't always assume that
the web server is going to be smart enough to understand the
installers speech impedement.