Apt-get stuck at 0% [Working]

Question

When I try to do anything with apt-get using a terminal, the apt-get gets stuck at 0% [Working].

Answer 1

An answer I did not find on the internet anywhere but actually found it based on a command I executed a couple of hours ago. An example of such a command is

echo "deb http://dl.bintray.com/tproenca/pmsarm7 jessie main" | sudo tee /etc/apt/sources.list.d/pms.list

After which a file is added to /etc/apt/sources.list.d/. In this directory, sources could also be added. In my case it was teamviewer which contained it's own list which had an invalid url. Therefore causing my update to fail. These are the commands that I executed.

Note: teamviewer.list was causing me problems but it can be anything for you inside this directory. Try it out and make back-ups!)

cd /etc/apt/
cp sources.list.d/* sources.list.d.backup/
rm sources.list.d/teamviewer.list
apt-get clean
apt-get check
apt-get rm -rf /var/lib/apt/lists/*
apt-get update

Hope this saves someone the hours it could have saved me!

Answer 2

In debian 9, my apt was stuck at 0%[working] for sometime before it does any task which requires access to internet. After trying many other methods, When i disabled the network manager and started using systemd-networkd instead, this problem was finally solved.

Answer 3

You can try to check the cache and to clean the cache directory.
In the order (each step is more deep, so stop as you find a solution):

• sudo apt-get clean (Update) on recent versions it will clear out the local repository of retrieved package files. It will be enough most of the time. It is (was) not so on earlier versions.

  It removes everything but the lock file from /var/cache/apt/archives/ and /var/cache/apt/archives/partial/.

• Look inside /var/lib/apt/lists/partial/ it should be empty.
  If not you can decide to empty it sudo rm /var/lib/apt/lists/partial/* eventually you may need sudo rm -f /var/lib/apt/lists/partial/*

• sudo apt-get check

  it updates the package cache and checks for broken dependencies.

• Shrink to a normal (not huge) number of repositories the list of /etc/apt/sources.list.
  If they are too many your system can hang in the attempt to build all the dependencies tree.
  You can create a minimal set of repositories from Ubuntu Sources List Generator site and after that you backup the /etc/apt/sources.list (with e.g. sudo cp -i /etc/apt/sources.list /etc/apt/sources.list.000) you can paste that instead of your present list.

• eventually you can check if you have a source lists file with https rather than http, but apt-transport-https is not installed (see the comment).
• try again sudo apt-get update and if it fails
• backup your /var/lib/apt/lists directory with sudo cp -r -p -i /var/lib/apt/lists ${HOME}/temp_apt_lists and after sudo rm -R /var/lib/apt/lists/*
• run sudo apt-get update again

It's possible you need to clean by hand some of the following directories (you can always backup them and only after delete the files inside) :

• /etc/apt/sources.list.d/
  File fragments for locations to fetch packages from. Configuration Item: Dir::Etc::SourceParts.
• etc/apt/preferences.d/
  File fragments for the version preferences. Configuration Item: Dir::Etc::PreferencesParts.
• /var/cache/apt/archives/partial/
  Storage area for package files in transit. Configuration Item: Dir::Cache::Archives (partial will be implicitly appended)
• /var/lib/apt/lists/partial/ Storage area for state information in transit. Configuration Item: Dir::State::Lists (partial will be implicitly appended)
• /var/lib/apt/lists/ Storage area for state information for each package resource specified in sources.list(5) Configuration Item: Dir::State::Lists.

PS> If you have succeed, remember to delete the backup copy that you don't need anymore, but not the sources.list.000 it can always be useful!
You can find additional hints in related answer as this one.

Update
There was an old bug because the package squid-deb-proxy-client does not clean up all its changes, solved so:

Removing the line:
Acquire::http::ProxyAutoDetect "/usr/share/squid-deb-proxy-client/apt-avahi-discover";

from:
/etc/apt/apt.conf.d/30autoproxy

Maybe can be useful this bug thread

More drastic remove the package if it is possible.

Answer 4

I also found this happening to me when I switched to some https repos. apt needs apt-transport-https to be installed in order to work (which understandably can be a problem when you're trying to download some stuff).

Answer 5

This could also be caused by being behind a proxy that blocks access. Sometimes I got a NODATA error... sometimes it just stayed at 0% [Working...].

Answer 6

Make sure you can ping out of your own network and more importantly to the Ubuntu network i.e.

 ping us.archive.ubuntu.com
 OR
 ping security.ubuntu.com

You should get an output similar to:

 PING security.ubuntu.com (91.189.88.161) 56(84) bytes of data.
 64 bytes from keeton.canonical.com (91.189.88.161): icmp_seq=1 ttl=52 time=127 ms
 64 bytes from keeton.canonical.com (91.189.88.161): icmp_seq=2 ttl=52 time=128 ms

  --- security.ubuntu.com ping statistics ---
  2 packets transmitted, 2 received, 0% packet loss, time 1000ms
  rtt min/avg/max/mdev = 127.325/127.952/128.579/0.627 ms

Answer 7

I came to this page via a high ranked Google search but these answers didn't help me. Instead I cleared out my local repository of retrieved package files with:

apt-get clean

Answer 8

first try to update it by

aptitude update

and then run apt-get

or should change your mirror to closest to your place, watch this - How can I get apt to use a mirror close to me, or choose a faster mirror?