Apt-get update very slow, stuck at “Waiting for headers”


This sounds like it may be an issue with third party repos. I know Google's repo takes several minutes to respond here sometimes. If you have third party repos set up, open Update Manager, click Settings, then the "Other Software" tab. Uncheck all checkboxes, then hit close.

Now, fire up a terminal and use the following command and see if it is any better with the following command:

sudo apt-get update

If it is better, go back and enable each repo and recheck one by one until you find the problem repo.

If that does not work, you can have the update manager select the best main repos to use automatically. To do that, open Update Manager, then click Settings. Select the Ubuntu Software tab, then in the "Download from:" dropdown, select Other...

Now, in the window that pops up, click "Select Best Server"

It will then perform several tests to select the best server for you. Once it is completed, just click Choose...

0 0
0 0


I have looked at similar questions:

Stuck at 0% [waiting for headers]

apt-get update stuck on "Waiting for Headers" when using Windows XP ICS

However neither one of them answer my problem.

I am running 12.04 AMD64 and have recently started getting an issue that when I update my repos from my connection at home through a terminal, using sudo apt-get update, it takes forever (literally after 2 hours it was at 28%), however when I run from a different location it takes less than 5 minutes to complete.

I have attempted changing which mirror I use but that does not solve the issue. I have also cut down what is in my sources list but this also makes no difference. There are no faults on my ADSL line as I have already contacted my ISP to check this. It also makes no difference if I use a WiFi or network cable connection.

What could be my issue?

A speed test (www.speedtest.net) comes out at about 0.9 Mbps...

0 0

If you're a Google chrome user on Ubuntu you may have noticed apt-get update seems to wait around for two minutes sitting at 99%. The culprit is the google apt repo having issues with http/1.1 pipelining. Fortunately there's a bug for it on Launchpad with a workaround that does the job. Thanks gozdal!

The solution boils down to turning off http/1.1 pipelining. Here's how (note the bug listed above lists the incorrect path to the conf dir):

Open /etc/apt/apt.conf.d/google-workaround.conf with your favorite editor. (You'll need sudo e.g. sudo vim or gksudo gedit).

Add the following line:

Acquire::http::Pipeline-Depth "0";

Save it and run sudo apt-get upgrade again and you should find it completes without the 2 minute...

0 0


root@SERVER1:~# apt-get update Get:1 lucid Release.gpg [189B] Ign lucid/main Translation-en_US Ign lucid/restricted Translation-en_US Ign lucid/universe Translation-en_US Ign lucid/multiverse Translation-en_US Get:2 lucid-security Release.gpg [198B] Ign lucid-security/main Translation-en_US Ign lucid-security/restricted Translation-en_US Ign lucid-security/universe Translation-en_US Ign lucid-security/multiverse Translation-en_US Get:3 lucid-updates Release.gpg [198B] Ign lucid-updates/main Translation-en_US Ign lucid-updates/restricted Translation-en_US Ign lucid-updates/universe Translation-en_US Ign lucid-updates/multiverse...
0 0

tldr; Software Source -> Download From -> Other -> Choose Best Server

I had this problem with an ubuntu install. To debug the problem I edited /etc/apt/apt.conf and added Acquire::http::Timeout "3"; which gives a really short timeout and makes it much more obvious what the problem is.

apt-get update then showed a lot of 404's from http://bg.archive.ubuntu.com which was the repository my ubuntu install had chosen.

Under software sources I then went to Download From -> Other -> Choose Best Server. It chose a server in Bulgaria - which actually happened to be the same server, which I suppose bg.archive.ubuntu.com is aliased or redirected to. But in any case, after selecting that server directly rather than the .archive.ubuntu.com alias, apt-get update worked perfectly. This suggests there can sometimes be some kind of problem with DNS or aliasing with the *.archive.ubuntu.com server names, which can simply be resolved by using another server, or even the same...

0 0
Alright, so I've had this problem for about a week now and have tried to research it myself and figure it out but it just doesn't make much sense. So here is all I've done to diagnose the issue...

So here is what results when I try to update:

root@proxmox:/etc/apt# apt-get update
0% [Connecting to ftp.us.debian.org] [Connecting to download.proxmox.com] [Connecting to security.debian.org]

It hangs like that for awhile and then:

root@proxmox:/etc/apt# apt-get update
Err http://download.proxmox.com squeeze Release.gpg
Connection failed
Err http://security.debian.org squeeze/updates Release.gpg
Connection failed [IP: 80]
Err http://download.proxmox.com/debian/ squeeze/pve Translation-en
Connection failed
Err http://security.debian.org/ squeeze/updates/contrib Translation-en
Connection failed [IP: 80]
0% [Waiting for headers] [Waiting for headers] [Waiting for headers]

It keeps doing...

0 0

This appears to be an intermittent issue. It works sometimes but fails most times.

Here is the scenario:

On a VM (e.g., socketplane-1) I create a new network.

sudo socketplane network create web

Then launch a new docker instance on that same host.

sudo socketplane run -n web -itd ubuntu:14.04

Then I attach to the docker instance.

sudo socketplane attach

The run the apt-get

sudo apt-get update

This works fine.

Then I jump onto a second host (e.g., socketplane-2) and do the following.

The I launch a new docker instance on the second host.

sudo socketplane run -n web -itd ubuntu:14.04

Then I attach to the docker instance.

sudo socketplane attach

The run the apt-get

sudo apt-get update

This is the hanging response...

root@e1ec329bdc1b:/# sudo apt-get update Ign http://archive.ubuntu.com trusty InRelease Ign http://archive.ubuntu.com...
0 0

Over the last month, an odd issue tripped up Linux distributions that use apt-get for updating and upgrading. Upon issuing the command sudo apt-get update, the process would stall when connecting with any of the default repositories or slow to a crawl when downloading headers during the update process.

After much troubleshooting and chasing down the wrong rabbit holes (such as DNS, cache, and gateway issues), I finally discovered the problem. You may be surprised at the solution.

SEE: System Monitoring Policy (Tech Pro Research)

The first failed fix

When this happened to me previously, the solution was to allow Software & Updates to download from the best server. To do this, you'd open Software & Updates, click the Download from the drop-down and select Other.

In the resulting window (Figure A), click Select Best Server and allow the system to set the ideal server for your location. Once that completes, click Choose Server, enter your sudo...

0 0

I have a problem making TCP connections after a fresh Ubuntu 14.04 installation. First of all, after booting the interface is always off. In my case the interface is manually configured and named em2. I turn it on using sudo ifup em2. After that, I can ping my gateway and public sites like www.example.com, and resolve DNS queries without issues.

However, when I try sudo apt update I have the same issue as apt-get update very slow, stuck at "Waiting for headers".

I'm also having issues with ssh in that it never connects from a remote location to the server and vice-versa. When trying to ssh to remote servers, I get the following errors:

debug2: Compat: skipping algorithm "curve25519-sha256@libssh.org" debug2: compat_kex_proposal: compat KEX proposal: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug1: SSH2_MSG_KEXINIT sent...
0 0

Binary package hint: apt

I installed google chrome in karmic and later lucid. Google chrome adds the following apt line to update itself:

deb http://dl.google.com/linux/deb/ stable main

When running apt-get update with this line installed it will hang for exactly two minutes saying "Waiting for headers". I've ran a wireshark dump of the connection and it seems to be stopping right after receiving Release.gpg. After some kind of timeout is reached it seems to close the connection and then download everything else and finish without problems.

Attached is the wireshark log of all this. Seems to be some kind of bug in how apt's http code handles the google server. Both wget and curl fetch the file without problems. Why does apt even need its own implementation of an HTTP...

0 0

As the title indicated, that is my problem.

Currently running an Rpi3 with Jessie, tried Stretch and the same problem occured.

when sudo nano /etc/apt/sources.list, I have:

deb http://mirrordirector.raspbian.org/raspbian/ jessie main contrib non-free r$

# Uncomment line below then 'apt-get update' to enable 'apt-get source'

deb-src http://archive.raspbian.org/raspbian/ jessie main contrib non-free rpi

Tried different mirrors, same problem.

When I ping mirrordirector, no problem. I can even go surfing the web on Chromium. Behaviour is similar for when I connect via Ethernet and WLAN.

I searched online and tried almost all solutions on this problem. I even enabled root (I know i'm not supposed to, I'll disable after I solve this problem).

Well when I sudo apt-get update, this is what I got.

root@raspberrypi:/home/pi# sudo apt-get update

Ign http://mirrordirector.raspbian.org jessie InRelease


0 0

Reproduction Steps:

Execute “sudo apt-get update” within container user@11611da3d377:/projects$ sudo apt-get update 0% [Waiting for headers] [Waiting for headers]

Expected behavior:
Able to do sudo apt-get update and install software.

Observed behavior:
I can observe that the apt-get update stops at [waiting for headers].

I troubleshoot the issue with the following steps. Confirm that able to ping but when doing wget/curl it seems to be able to connect but not getting response.

ubuntu@dev14-04:~$ docker run -itd --name=container1 busybox 545bf50a46d798602e21d04b177ab9500c48af5c8b37b2773204067631507211 ubuntu@dev14-04:~$ docker attach container1 / # ping -w3 www.google.com PING www.google.com ( 56 data bytes 64 bytes from seq=0 ttl=53 time=24.949 ms 64 bytes from seq=1 ttl=53 time=22.862 ms 64 bytes from seq=2 ttl=53 time=22.751 ms --- www.google.com ping statistics --- 3 packets...
0 0

RaspBMC? I wonder if there are some bits that have been taken out?

Does the file /usr/lib/apt/methods/xz exist? Actually, just list the contents of that whole directory

Code: Select all

pi@raspi2 ~ $ ls -l /usr/lib/apt/methods total 448 lrwxrwxrwx 1 root root 4 Jan 19 05:30 bzip2 -> gzip -rwxr-xr-x 1 root root 34252 Jan 19 05:44 cdrom -rwxr-xr-x 1 root root 17868 Jan 19 05:44 copy -rwxr-xr-x 1 root root 17868 Jan 19 05:44 file -rwxr-xr-x 1 root root 58860 Jan 19 05:44 ftp -rwxr-xr-x 1 root root 30156 Jan 19 05:44 gpgv -rwxr-xr-x 1 root root 21964 Jan 19 05:44 gzip -rwxr-xr-x 1 root root 79312 Jan 19 05:44 http lrwxrwxrwx 1 root root 4 Jan 19 05:30 lzma -> gzip -rwxr-xr-x 1 root root 107984 Jan 19 05:44 mirror -rwxr-xr-x 1 root root 34252 Jan 19 05:44 rred -rwxr-xr-x 1 root root 30164 Jan 19 05:44 rsh lrwxrwxrwx 1 root root 3 Jan 19 05:30 ssh -> rsh lrwxrwxrwx 1 root root 4 Jan 19 05:30 xz -> gzip

and while you're at it, check the xz executable...

0 0

Hello all. I recently setup a new server to act as a dedicated apt-cacher server for all the obvious reasons. I have Ubuntu 8.04.2 LTS installed on all servers.

It seems as though running apt-get update from the apt-cacher server as well as the other regular servers is overall much slower going through the apt-cacher proxy than going direct to internet. My environment is fully Gbit (to internet as well) and hardware is more than sufficient. There are two local resolvers that are underutilizied and run properly.

Sometimes the updates go slow, sometimes they just sit at 99% [Waiting for headers] for about 10 minutes and then it fails (only on some of the repositories, and only sometimes). The updates are actually coming through correctly, and are getting cached and sent on down correctly.

Any ideas on what this speed issue is all about?
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at:...

0 0
Stuck at 0% [Waiting for Headers] How can I fix this?

location: ubuntuforums.com - date: September 19, 2013
My system was working fine before I installed Pantheon, now after the installation, I can't install any package. I ran these commands: sudo apt-add-repository -y ppa:elementary-os/daily sudo apt-add-repository -y ppa:midori/midori-dev sudo apt-add-repository -y ppa:ricotz/docky sudo apt-add-repository -y ppa:marlin-devs/marlin-daily sudo apt-get update sudo apt-get install elementary-desktop and after that, I did: sudo apt-get remove elementary-desktop sudo apt-get remove pantheon now, whenever I try to install any package, I get stuck at stuck at 0% [Waiting for headers] - and when I do sudo apt-get update, I get stuck at 100% [Waiting for headers] - How can I fix this? I would appreciate it if you can help me.

Waiting for headers...

location: ubuntuforums.com - date: August 1, 2011
My machine here won't update or wget anything. It just sits "Waiting...

0 0