7

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 http://eu-west-1.ec2.archive.ubuntu.com/ubuntu/dists/oneiric-updates/Release.gpg  
Unable to connect to eu-west-1.ec2.archive.ubuntu.com:http: [IP: 10.224.87.159 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?

3
  • 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). Sep 23, 2011 at 20:27
  • 1
    Can't get to the server either. Just use another mirror.
    – arrange
    Sep 23, 2011 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. Sep 23, 2011 at 21:11

2 Answers 2

10

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://mirrors.ubuntu.com/mirrors.txt 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.

4
  • Aha, now I understand it. I built this box off of the Amazon AMI images on cloud.ubuntu.com 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. Sep 23, 2011 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. Sep 23, 2011 at 21:36
  • 1
    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. Sep 24, 2011 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 us-west-2.ec2.archive.ubuntu.com 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, 2015 at 21:03
0

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 security.ubuntu.com (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 archive.ubuntu.com, it succeeds elsewhere

ex from my script in cloud-init:

us-east-1.ec2.archive.ubuntu.com is an alias for us-east-1.ec2.archive.ubuntu.com.s3.amazonaws.com.
us-east-1.ec2.archive.ubuntu.com.s3.amazonaws.com is an alias for s3-1-w.amazonaws.com.
s3-1-w.amazonaws.com has address 205.251.242.197
nc: connect to us-east-1.ec2.archive.ubuntu.com port 80 (tcp) timed out: Operation now in progress
Connection to {myawsserver}.ec2.{somedomain} 80 port [tcp/http] succeeded!
Connection to security.ubuntu.com 80 port [tcp/http] succeeded!
2
  • 1
    This is more of a comment than an answer. Do you have a solution?
    – jmunsch
    Apr 10, 2014 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, 2014 at 1:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .