Red Hat Bugzilla – Bug 34931
HTTP network installs fail with FTP IO error
Last modified: 2007-04-18 12:32:33 EDT
Attempting to install RH7 over a network *always* fails via HTTP, but
works fine via FTP. I've tried both TUX 2.0 and IIS 5.0 as Web servers,
both fail the same way.
Using a browser, I can GET /path/RedHat/base/netstg1.img just fine, but I
get an "FTP IO error" from the RH7 bootnet disk.
Let me stress that FTP works fine with the same IP address and path, so
networking is not the problem. The 3c59x driver is loaded and works
Steps to Reproduce:
1. Create RH7 boot disk from bootnet.img on RH7 CD1
2. Boot a machine with that floppy (Dell Precision 410 in my case)
3. Choose HTTP network install, enter IP address and path of where files
are on web server.
Actual Results: Get a dialog box with the error "Failed to
retrieve /RH7/RedHat/base/netstg1.img: FTP IO error"
Then a second dialog box with title "HTTP" and body "Unable to retrieve
the first install image"
Expected Results: The network images should have been downloaded (as the
FTP network install does) and installation should have proceeded.
VC3 showed the 3c59x NIC was found, and I can ping this machine from the
Web server. VC3 also shows "transferring
http://188.8.131.52//RH7/RedHat/base/netstg1.img to a fd" for every failed
I used a packet monitor on the network to determine that the GET request
*does* come into the Web server, and it sends netstg1.img to the client
without problems. I have no idea why the installer is giving an FTP IO
error message (esp since it's HTTP).
HTTP installs *do* work with Red Hat Linux 7. Our QA dept. tests all of the
installation methods, although our HTTP servers are all Red Hat Linux running
Apache. I don't think TUX or IIS has been tested as an HTTP installation
server. Having said that, I'm not sure why it's not working for you. Since the
GET request is reaching the web server, it looks like the server isn't
responding correctly to the request. Have you tried pointing a different
machine at the web server and see if you can pull netstg1.img over via a web
browser. That would take the installer completely out of the equation, so maybe
we can narrow the problem down a little.
> Have you tried pointing a different machine
> at the web server and see if you can pull
> netstg1.img over via a web browser.
Yes, in the original bug report above I said "Using a browser, I can
GET /path/RedHat/base/netstg1.img just fine, but I get an "FTP IO error" from
the RH7 bootnet disk."
I will attempt to install tomorrow with Red Hat/Apache and let you know what
I just tested with Red Hat/Apache 1.3.19 (from RH 7.1) and it works great. I
just tested TUX 2.0 (also from RH 7.1) and it failed, although GETs with a
browser again worked fine.
I'm going to attach a tarball that shows a tcpdump of the Apache case and the
TUX case. The Apache one is larger, obviously, since it successfully sends
Created attachment 15347 [details]
tcpdump of Apache and TUX GET requests during HTTP net install
Hmm. Thanks for your information. This is an interesting problem. I will look
at your tcpdump info when I have more time. I wonder what is different about
the other web servers that makes things not work. This very well could be an
installer problem. I wonder if connecting to an Apache server running on a
Windows box would work...
Actually, this problem has been reported before. Resolving as a duplicate.
*** This bug has been marked as a duplicate of 23037 ***
The problem seems to be in Anaconda, file loader/ftp.c
Line 445 reads:
sprintf(buf, "GET %s \"HTTP/1.0\"\r\n\r\n", remotename);
This specifically includes quotes around HTTP/1.0. IIS and
who knows what other web servers don't like this. Apache seems
to ignore it. I don't see the quotes in the HTTP spec at www.w3c.org, FWIW.
This problem still exists in Seawolf, so the problem is not with old Python
libs, as Brent suggested.
Can we put the text of the solution of the other bug (23037) in this one also?
The other bug is a non-public bug, so Mark (firstname.lastname@example.org) is unable
to view it ... :)
Ok, we'll take another look at this one.
Here's an excerpt from the HTTP/1.1 spec (of course, we're using HTTP/1.0, so
things may differ)
The absoluteURI form is REQUIRED when the request is being made to a
proxy. The proxy is requested to forward the request or service it
from a valid cache, and return the response. Note that the proxy MAY
forward the request on to another proxy or directly to the server
specified by the absoluteURI. In order to avoid request loops, a
proxy MUST be able to recognize all of its server names, including
any aliases, local variations, and the numeric IP address. An example
Request-Line would be:
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
To allow for transition to absoluteURIs in all requests in future
versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
form in requests, even though HTTP/1.1 clients will only generate
them in requests to proxies.
The authority form is only used by the CONNECT method (section 9.9).
The most common form of Request-URI is that used to identify a
resource on an origin server or gateway. In this case the absolute
path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
the Request-URI, and the network location of the URI (authority) MUST
be transmitted in a Host header field. For example, a client wishing
to retrieve the resource above directly from the origin server would
create a TCP connection to port 80 of the host "www.w3.org" and send
GET /pub/WWW/TheProject.html HTTP/1.1
followed by the remainder of the Request. Note that the absolute path
cannot be empty; if none is present in the original URI, it MUST be
given as "/" (the server root).
So, saying something like:
GET /index.html HTTP/1.1
works on IIS. It also works on Apache, for what it's worth. I don't know if it
works on TUX or not.
Yes, but saying
GET /index.html "HTTP/1.1" (quotes intended, and included from Anaconda source code)
does _not_ work on IIS.
We're doing this now in the loader:
sprintf(buf, "GET %s HTTP/1.1\t\nHost: %s\r\n\r\n", remotename, hostname);