Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to do an apt-get update or apt-get install xyz and I'm seeing timeouts like this:

W: Failed to fetch  
Unable to connect to [IP: 80]

Is this a transient issue with Ubuntu, or maybe it's something on my end. The box I'm accessing it from is in EC2-EU.

Perhaps there is a way to force the installer to use the US servers which seem to work?

share|improve this question
I might note that I don't see this issue from a US box, only from the server running in the amazon EU datacenter (Ireland). – David Parks Sep 23 '11 at 20:27
Can't get to the server either. Just use another mirror. – arrange Sep 23 '11 at 21:09
How do I change mirrors? If you could post some bit of direction on that as an answer it would be a great help. – David Parks Sep 23 '11 at 21:11
up vote 10 down vote accepted

Firstly, I assume the timeouts are a transient problem with Ubuntu update servers in that region.

It should be noted that EC2 Ubuntu AMIs point to update servers hosted on the EC2 region you are using. It's fast (~10Mbps) and you don't pay for the bandwidth.

Having said that, there's nothing enforced about where you get your updates from. You can change your /etc/apt/sources.list to point to different update servers in a different region. Two suggestions for a workaround:

  • copy a sources.list from the US region over to your EU hosts.
  • add the following line to the top of your sources.list:
    deb mirror:// oneiric main restricted universe multiverse

What's neat about the second solution is that this "mirrors.txt" file is dynamically generated via GeoIP and should always return a good and relatively close mirror. It's great for us Ubuntu users who find themselves travelling frequently.

Again, given the special nature of the archive servers on EC2, I wouldn't normally do this on a cloud instance. And I would only do either of these workarounds as a temporary measure. The problem, wherever it may be, is transient and I would expect it to be fixed fairly quickly.

share|improve this answer
Aha, now I understand it. I built this box off of the Amazon AMI images on and it plugged in the local server (which is not working as it appears). I commented out all lines with that server and added your mirror:// line at the top and things seem to work. Let me know if commenting out all the other lines has some negative side effects. – David Parks Sep 23 '11 at 21:25
Hmm. That's pretty interesting. It didn't occur to me that the deb mirror:// line would work all by itself, but it makes sense now that you mention it. As long as it's working, I don't see a problem at all. Having said that, it would probably work just as well with the original entries left intact. The mirror line just needs to come first. – Mark Russell Sep 23 '11 at 21:36
There were about 6 lines referencing the bad server, it did work commenting them out and leaving just this line, I was able to do the installs of all the software I needed. – David Parks Sep 24 '11 at 20:51
I have had this issue a couple times. I have an extra ENI and extra ip route/rules to handle it.. and works fine after configured, but if i leave the instance for a time (weeks), and come back to it, my connectivity to does down. Rebooting the instance brings it back up.. haven't investigated into what may be interrupting with the ip route/rules... – sonjz Aug 4 '15 at 21:03

I'm seeing similar behavior with a cloud-init process when I am assigning an elastic IP as part of the metadata for launching an instance.

The strange thing is I'm only seeing sporadic timeouts one and off for about 30 seconds while cloud-init is running. I'm testing this with a netcat that runs every 2 seconds as part of the cloud-init. I'm getting nc timeouts every few times for a while, and then it stabilizes. DNS seems to work every time and occasionally gives me a different IP (as expected).

I'm suspecting something to with the elastic IP assignment in the AWS infrastructure but I'm not sure.

The other interesting piece is that http connections to a local repo in my AWS account work fine, and calls to (external to AWS I believe) work fine too. I've only been able to collect about 15 samples so far. I do have confirmation that when a netcat fails to, it succeeds elsewhere

ex from my script in cloud-init: is an alias for is an alias for has address
nc: connect to port 80 (tcp) timed out: Operation now in progress
Connection to {myawsserver}.ec2.{somedomain} 80 port [tcp/http] succeeded!
Connection to 80 port [tcp/http] succeeded!
share|improve this answer
This is more of a comment than an answer. Do you have a solution? – jm_____ Apr 10 '14 at 0:44
Correct - I'm still working on a solution and mis-posted this as a answer instead of a comment. I'll ask for a removal. Thanks. – Sellers Apr 10 '14 at 1:55

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.