I was not able to install via HTTP. It returned an error that it couldn't retrieve netstg1.img. The same directory worked for an FTP install (and the file is plainly accessible to lynx or netscape or wget). The web server is a thttpd server.
Assigning to a developer.
Can you check the web server logs to make sure that the install is looking for the file you think it is?
This defect is considered MUST-FIX for Florence Gold release
More info from a beta2 install ... Using pcmcia (with the pcmcia.img + pcmciaadd.img) install or text mode install (with the bootnet.img). The webserver is a thttpd server from 7.0 Powertools on a standard 7.0 install (with ext3 beta upgrades, not that that would matter any). Selected webserver '10.2.5.10' (also tried by the hostname) path '7.1' (also tried '/7.1/' and '7.1'). The webserver log records NO hit. The install console reports: transferring http://10.2.5.10/7.1/RedHat/base/netstg1.img to a fd The install screen reports: failed to retrieve 7.1/RedHat/base/netstg1.img: Bad FTP server response. (Note the 'FTP' even though I selected HTTP.) The webserver can access the install client (verified with ping). The install client can access the webserver (works fine in FTP mode). The webserver works fine. From another station $ lynx -source http://10.2.5.10/7.1/RedHat/base/netstg1.img | md5sum c0897ef501b24d6433dfa08323d6c541 - The webserver log reports: 10.2.5.1 - - [11/Jan/2001:14:04:19 -0800] "GET /7.1/RedHat/base/netstg1.img HTTP/1.0" 200 1962770 "" "Lynx/2.8.4dev.7 libwww-FM/2.14" From the server: # md5sum 7.1/RedHat/base/netstg1.img c0897ef501b24d6433dfa08323d6c541 7.1/RedHat/base/netstg1.img If I go back and select the identical options with FTP, it works. The webserver root and the FTP server root are the same directory. Maybe I'm missing something, but I just can't get it to work :(
PCMCIA was foobar'd in this beta -- is fixed internally
Sorry if I wasn't clear, this happens with normal bootnet.img installs as well as the PCMCIA installs, with the same error message. The bootnet.img install was on a plain old Dell Desktop with an Intel eepro100.
Hmm, so much for the easy answer. Could you tcpdump that link to see what http traffic is being generated?
Here is a TCP dump, this time the server is a 7.1 machine running the 7.1 powertools thttpd. Again, nothing shows up in the thttpd logs. I'm guessing thttpd doesn't like HTTP/0.9? 08:54:12.364048 eth0 < 10.15.10.29.32768 > poe.corp.jalan.com.http: . 1:1(0) ack 1 win 5840 <nop,nop,timestamp 3292 41793270> (DF) 08:54:12.364219 eth0 < 10.15.10.29.32768 > poe.corp.jalan.com.http: P 1:46(45) ack 1 win 5840 <nop,nop,timestamp 3292 41793270> (DF) 08:54:12.364260 eth0 > poe.corp.jalan.com.http > 10.15.10.29.32768: . 1:1(0) ack 46 win 5792 <nop,nop,timestamp 41793270 3292> (DF) 08:54:12.364596 eth0 > poe.corp.jalan.com.http > 10.15.10.29.32768: P 1:484(483) ack 46 win 5792 <nop,nop,timestamp 41793270 3292> (DF) 08:54:12.364623 eth0 > poe.corp.jalan.com.http > 10.15.10.29.32768: F 484:484(0) ack 46 win 5792 <nop,nop,timestamp 41793270 3292> (DF) 08:54:12.366483 eth0 < 10.15.10.29.32768 > poe.corp.jalan.com.http: . 46:46(0) ack 484 win 6432 <nop,nop,timestamp 3292 41793270> (DF) 08:54:12.367520 eth0 < 10.15.10.29.32768 > poe.corp.jalan.com.http: R 46:46(0) ack 484 win 6432 <nop,nop,timestamp 3292 41793270> (DF) 08:54:12.368005 eth0 < 10.15.10.29.32768 > poe.corp.jalan.com.http: R 972839868:972839868(0) win 0 (DF) $ telnet poe.corp.jalan.com 80 Trying 64.22.132.134... Connected to poe.corp.jalan.com (64.22.132.134). Escape character is '^]'. HEAD / HTTP/0.9 HTTP/0.9 400 Bad Request Server: thttpd/2.16 29feb00 Content-type: text/html Date: Wed, 17 Jan 2001 16:59:08 GMT Last-modified: Wed, 17 Jan 2001 16:59:08 GMT Accept-Ranges: bytes Connection: close I verified that it works fine with Apache, though. Why is anaconda using HTTP/0.9? It would be best to support 1.1 to allow installs/upgrades off name-based vhosts. Supporting 1.0 seems to be the easiest thing, but if this is not possible it is probably worth reporting or documenting that the installer requires Apache or another HTTP/0.9 compatible server.
Very likely -- could you try w/ apache?
See my last note. It works fine with Apache.
Sorry, I didn't see that bit. This isn't an install bug, but a thttp one instead.
It's not a thttpd bug because other web servers that don't support 0.9 (the 'ass-backwards version) won't work. Additionally, using 0.9 means that you can't use named virtual host installs with any web server. I've renamed this bug and re-opened it as a RFE. Upgrading at least to support HTTP/1.0 should be trivial, though I'll admit that it is an enhancement and not a bug, per se.
True, but we use python's http support, and we get what we get...
This was in the loader, actually. I changed it to use HTTP 1.0 instead, which was straightforward. Making it use 1.1 would also be easy, but pointless because then then python would need hacking. Should be done someday though.
*** Bug 34931 has been marked as a duplicate of this bug. ***
The loader is 1.1 now; the python probably isn't.