installation hangs if the computer is behind a proxy

*** Bug 15055 has been marked as a duplicate of this bug. ***

*** Bug 15241 has been marked as a duplicate of this bug. ***

*** Bug 15427 has been marked as a duplicate of this bug. ***

I was also affected by this bug, installing Ubuntu 5.04.

There's no point at which I can tell the Ubuntu installer about my HTTP proxy, and it proceeds to hang for upwards of an hour while timing out repeatedly,
as there's no outgoing HTTP access from this machine.

*** Bug 17575 has been marked as a duplicate of this bug. ***

This is a combination of the following:

  * apt's default HTTP timeout is 120 seconds

  * apt tries each IP address for the archive in turn

  * apt tries all of dists/hoary/Release,
dists/hoary/main/binary-$ARCH/Packages.bz2,
dists/hoary/main/binary-$ARCH/Packages,
dists/hoary/restricted/binary-$ARCH/Packages.bz2,
dists/hoary/restricted/binary-$ARCH/Packages in succession, and doesn't remember
that it timed out on previous ones

When you multiply these together, and multiply by two again to take into account
the way we test both the primary repository and the security updates repository,
this comes to 40 minutes' worth of waiting around.

mvo, would it be possible to make apt a little more intelligent about this, and
at least remove the five successive timeouts in the third point above, please?
I'd hope that it should be reasonably straightforward to remember that the
request for Release timed out and not bother with the various Packages files.

In the meantime, I'll probably add some workaround like testing with wget before
running apt-get update.

(In reply to comment #6)
> This is a combination of the following:
[..]
> mvo, would it be possible to make apt a little more intelligent about this, and
> at least remove the five successive timeouts in the third point above, please?
> I'd hope that it should be reasonably straightforward to remember that the
> request for Release timed out and not bother with the various Packages files.

I put a fix for that in the
<email address hidden>/apt--sane-handle-timeout--0 branch.
The timeout can be configured with Acquire::http::Timeout and if fetching the
Release.gpg file fails with a timeout error it will assume it not try to get the
rest (assuming the network is dead).

Cheers,
 Michael

(In reply to comment #7)
> (In reply to comment #6)
> > This is a combination of the following:
> I put a fix for that in the
> <email address hidden>/apt--sane-handle-timeout--0 branch.
> The timeout can be configured with Acquire::http::Timeout and if fetching the
> Release.gpg file fails with a timeout error it will assume it not try to get the
> rest (assuming the network is dead).

This means of course that there will still be two timeouts, one for archive.u.c
and one for security.u.c. It will be one timeout for each enabled line in the
sources.list.

*** Bug 9209 has been marked as a duplicate of this bug. ***

*** Bug 19563 has been marked as a duplicate of this bug. ***

To install Ubuntu or KUbuntu when a proxy is required, at the CD boot prompt enter:

boot> linux http_proxy='http://<yourproxyhere>:<yourproxyporthere>'

Obviously you want to replace the <...> contents with your proxy info...

--
Rob.

Here is another update: it turned out that just looking for timout errors from
the method is not enough. Another very common cause is EAI_AGAIN from
getaddrinfo. This is reported now to the acquire code as well and apt fails
early for here too.

I hope this catches all network errors early now. The fix is in my
<email address hidden>/apt--mvo--0 tree (patch-47).

Cheers,
 Michael

Is this still an issue in current Breezy?

This is still an issue in Breezy RC, 6 Oct 2005. It seems that simply creating a
dialog asking if the system is behind a proxy server before testing network
repositories would easily solve this issue.
To me this is a showstopper. I like to leave CDs around at work for people to
try out. My company has over 15,000 employees world wide, probably 500 in this
location. If they try installing this software on spare systems at work, they
will quickly become discouraged with this bug, not knowing why the system hangs.
Please consider adding this to Breezy this next week if possible.
Thanks!

(In reply to comment #14)
> This is still an issue in Breezy RC, 6 Oct 2005. It seems that simply creating a
> dialog asking if the system is behind a proxy server before testing network
> repositories would easily solve this issue.

I just tried to reproduce the problem with a current daily and the install did
not hang and worked fine.

I wasn't asked for a proxy either and the network sources in
/etc/apt/sources.list are disabled though.

this bug still exists, even in ubuntu 5.10 server, which is, as well, a major
show-stopper for anyone behind a corporate firewall. the installer simply
hangs. i aborted installation after waiting 10 minutes. amazing that this has
been going on for so long, and not gotten fixed. debian installer handles this
just fine.

This is still a problem. Dapper now asks for proxy info, but the format it asks for is not the format that busybox's wget wants. Normal wget expects http://user:pass@host:port/ but busybox wants user:pass@host:port and causes long timeouts otherwise.

Problem also confirmed with 5.10. I have a Wi-Fi network card installed (and no other NIC) but installer did not recognize it. therefore it has no connection to the internet and this is prevent me from installing Ubuntu on this machine because of that timeouts.

The same is #31624, #35437 and more others.

Why it was not fixed yet (my first report - this thread - was more than a year ago)? This keeps A LOT of people out of the Ubuntu world - they just cant install it!

Is this issue still present in dapper?

This is still an issue for Ubuntu 6.06 LTS. I had to wait maybe half an hour. I wasn't asked if I have a proxy before.

This will be fixed between the Edgy release candidate and the final release (because it's too late for the RC now) by this upload:

apt-setup (1:0.11ubuntu5) edgy; urgency=low

  * Don't bother validating network mirrors if the base system can be
    installed from CD; apt's failure mode is sufficiently graceful nowadays
    that we can let the user sort out problems after installation (closes:
    Malone #14599, #35364).

 -- Colin Watson <email address hidden> Wed, 18 Oct 2006 18:47:47 +0100

apt-setup (1:0.11ubuntu5) edgy; urgency=low

  * Don't bother validating network mirrors if the base system can be
    installed from CD; apt's failure mode is sufficiently graceful nowadays
    that we can let the user sort out problems after installation (closes:
    Malone #14599, #35364).

 -- Colin Watson <email address hidden> Wed, 18 Oct 2006 18:47:47 +0100

I have just tried to install 6.10 RC and it stalls when the installation is updating via apt. So this problem seems to persist

i confirm this bug still in feisty (LiveCD). I am behind a proxy requiring authentication, maybe the problem occours just in that combination. After all it is possible to 'skip' (button) that part, but i think an ordinary user is not happy with this solution.

well, i think this could be closed because now, when running programs, gnome exports the http_proxy environment var thus ubiquity works well behind a proxy if you firstly configure your proxy server using "system=>preferences=>proxy" and i think this is right

This is still a problem in Gutsy Daily build 10 Oct.

Sorry, I didn't wait long enough. Not a problem in Gutsy

I think I just duplicated this with the 20071026 Ubuntu desktop i386 CD. The test setup was that I disabled external connectivity in my firewall for the machine on which I tested this. It has LAN access, and can do DNS queries, but cannot access the Internet otherwise. The installer got stuck for over 30 minutes in the phase where it verifies apt sources.