Bug 207278

What did you enter for the install location?

site: download.fedora.redhat.com
folder: pub/fedora/linux/core/development/i386
---
This was repeatable this morning with a one day newer: (but probably 1 day old)
1e56a6b85aab92d57dc88adda25ab3ac8a592ad0  FC-development-i386-rescuecd.iso

This time it ended up trying 1-10/10 for
ftp://download.fedora.redhat.com/%2F/pub/fedora/linux/core/
development/i386/os/Fedora/RPMS/libXv-1.0.1-4.1.i386.rpm failed

I checked the folder in firefox (ftp) and I could change folders to the folder
above os, but then attempting to enter into either iso or os folders I get a:
  ~"Too many connected users from your address" dialog.

There is only one machine within my NAT firewall trying to access the ftp site.

Trying again a few minutes later (in firefox) and I was able to read the folder
and download the .rpm listed above without problem (on another machine).

At this stage it returned to the package installation status screen showing 0/0
packages upgraded.

The user interface (text) was able to choose retry after about 5 minutes, and
then gets to cant dl .../info....rpm.

Hmm... could be related to keepalive stuff potentially

With rescue image: dff4bff3236c3c8434fbcda70baa7806b8d0bdfb 
FC-development-i386-rescuecd.iso  2006-09-26, this is repeatable (on same
notebook). Also repeatable when performing new install and formatting all
partitions.
--
On VT3 same messages appear (this time for rpm-libs-4....)
VT2: ftp download.fedora.redhat.com
Trying 209.132.176.20...
Connected to download.fedora.redhat.com (209.132.176.20)
421 There are too many connections from your internet address.
--
I'll repeat tonight on another machine/different mirrors/http.

Yep - I can confirm this with FC6 as shipped. People can download the CD images
onto a HDD and point the installer at the directory containing them using the
"Local HDD" option, AFAIK.

I'm gonna try that.

HTH

I think the problem here is that anaconda sometimes spuriously suffixes a "./"
to the install URL. I've seen this with HTTP installs. For example, consider the
case where I have an FC6 DVD ISO mounted on the root of a HTTP server (e.g.
http://10.0.0.1/). What do I enter in anaconda?

a) Enter "10.0.0.1" for the "Web site name" and nothing for the "Fedora Core
Directory" -> anaconda won't let me do it, saying "You must enter a directory"

b) Enter "10.0.0.1" for the "Web site name" and "/" for the "Fedora Core
directory" -> anaconda requests files using HTTP requests like this: (from an
Apache log):
GET /./RELEASE-NOTES-en_US.UTF-8.html HTTP/1.1" 404 406 "-" "urlgrabber/2.9.9"

Note the spurious "./". Now, in the case of Apache, it happens to ignore this
but this probably isn't the case for all HTTP/FTP servers and anaconda shouldn't
generate noise like that.

(It seems to me that it would also make more sense just to have a single URL
input instead of the weird split between hostname and path.)

Is this fixed in F8 test 2?  (Note that this release isn't quite out yet, but I
think we have this issue taken care of.)

I tried for a giggle with F8t1 rescue iso. This seemed to be going OK, but got
to the same WARNING message on VT3:
23:35:16 WARNING : Try 10/10 for ftp://download.fedora.redhat.com/%2F/pub
/fedora/linux/releases/test/7.90/Fedora/i386/os/Fedora
/libxklavier-3.2-1.fc8.i386.rpm failed
23:35:16 WARNING : Failed to get ftp://download.fedora.redhat.com/%2F/pub
/fedora/linux/releases/test/7.90/Fedora/i386/os/Fedora
/libxklavier-3.2-1.fc8.i386.rpm from mirror 1/1

There is two warning messages at each second, so perhaps it tries every 0.5 seconds.

VT1 {in text mode}:
Welcome to Fedora
 The file libxklavier-3.2-1.fc8.i386.rpm cannot be opened.   
 This is due to a missing file or perhaps a corrupt          
 package.  Please verify your mirror contains all required   
 packages, and try using a different one.                    
                                         tarting 
 If you exit, your system will be left in an inconsistent    
 state that will likely require reinstallation. 
           Reboot                 Retry

In this attempt, a check of the download url using firefox shows the file is
present at the URL, can be downloaded and the rpm extracts with fileroller.

Pressing retry {after 8 hours} allows it to continue {Starting install process}.
It then had 2 misses with libdhcp, but succeeded on third attempt.
Had 2 misses on another file, but proceeded {again without showing a
retry/reboot dialog}.
Then 4 minutes later, 10 misses with libxslt-1.1.21-1.fc8.i386.rpm and the error
dialog.
Went OK for a few minutes and then:
07:48:30/31/31/32/32 5 misses on pap...rpm which is present
07:49:11/12/13/13/14/14 5 + fail on pap...rpm
Retrying within one minute failed, but waiting more than a few minutes then
retry succeeds in getting that file.

It seems to be the mirror {master} is rejecting the download. If that is the
case it is a bad thing, because it could lead to broken install / upgrades on
user machines.
However, the installer might be able to handle the situation better:
- ie not 5x tries only 0.5 second apart.
- actually look at the error message returned in the attempted get.
- provide the error message to the user.
- keeping the connection alive {I imagine wget is run for each new path. If so,
then instead of one connection to the ftp server, there is potentially 1000's of
connections {that might be considered DenialOfService attempt.
====
Last two boot isos 2007-08-25/26 have another error {bug 254681} which makes it
so this is not currently testable.

Well anaconda in rawhide is no longer adding the %2F to URLs it tries to get, so
hopefully the original problem here will go away.  If F9t1 clears this problem
up, we can go ahead and close this bug report out.

As for your specific suggestions:
(1) I don't see any relevant options in the urlgrabber package, so we will have
to implement the waiting in anaconda ourselves.
(2) and (3) are way harder to do than it should be.  There are a whole lot of
layers of code involved here and the real exceptions get interpreted and
re-raised several different times so once we know that an error has occurred, we
really can't figure out what it was.
(4) We actually use urlgrabber, which supports keepalive connections for HTTP
but I don't know that it does for FTP.  This should be a separate bug against
that python module.

This bug seems related to {bug 152378} and {bug 237548} (see my
comments at the end of the latter). Does anybody know a mirror which
accepts the spurious /%2F/ (trying desesperately to install F8)?

Is this better in F9 Alpha?

Yes.
Detail:
1. Booted http://mirror.pacific.net.au/ ...
linux/fedora/linux/releases/test/9-Alpha/Fedora/i386/os/images/boot.iso
on vmware-server-1.0.4 on F8 {kernel-2.6.23.14-115.fc8}
2. Entered URL:
ftp://download.fedora.redhat.com/pub/fedora/releases/test/9-Alpha/Fedora/i386/os
Result:
a. It's sitting for a long time at preparing to install {2+hours}.
b. vt shows WARNING try 1/10 of xxxx.rpm failed.
c. seems to do nothing for some minutes, then continues, usually having the same
problem again.
The failed paths no longer contain /%2F/.

Closing this bug resolved as reported {however reporting a fresh bug to keep
other symptoms separate}.