I was recently having issues upgrading Debian Linux due to You don't have enough free space in /var/cache/apt/archives/ errors, and it took an hour or so to resolve the root cause of the issue (one program consuming far too much space). Hopefully this post will help cut down the debugging time for other people who run into this problem.

Upgrading packages

Debian has decent guides on upgrading packages (see guides for upgrading stable or testing releases), which are good to follow and give pointers for common issues.

I was able to run sudo apt update to fetch the latest list of available packages, and sudo apt-get upgrade to upgrade packages that didn’t require other packages to be removed or installed. However, when running sudo apt full-upgrade to complete the main part of the operating system update, the process failed with the message: E: You don't have enough free space in /var/cache/apt/archives/.

The Debian guides have a few tips for how to free up space, which were a good starting point, after which I had to go a bit further to figure out what exactly was taking up all the space in /var.

Starting with the basics: apt-get autoremove and apt-get clean

The first steps are to clear unused packages via sudo apt-get autoremove, and remove old install files from the package cache via sudo apt-get clean.

This wasn’t enough in this case, I still didn’t have enough space to run the OS upgrade.

Uninstalling packages which are no longer needed

This StackOverflow answer provided the following command for listing manually installed packages minus those from the base Debian install:

sudo grep -oP "Unpacking \K[^: ]+" /var/log/installer/syslog | sort -u | comm -13 /dev/stdin <(apt-mark showmanual | sort)

WARNING: The generated list will still include some packages which may not be safe to uninstall. However, if you see packages you know you no longer need, you can mark them as automatically installed to signal to the package manager that they can be safely uninstalled if no other installed packages depend on them.

sudo apt-mark auto PACKAGENAME, replacing PACKAGENAME with the package you don’t think you need anymore (eg. sudo apt-mark auto 2048-qt), marks the given package as automatically installed.

After marking several packages as automatically installed (eg. mutt and 2048-qt), I ran sudo apt-get autoremove to uninstall all packages which were marked as automatically installed and not depended on by any other installed packages.

This cleared up a few hundred megabytes, but not the gigabytes I needed for the OS upgrade.

Isolating directories taking up the most space

df is a helpful utility for reporting disk space usage across mounted file systems, where df -h displays sizes in a more readable format (eg. 26G instead of 27262976 for 26 gigabytes).

df -h immediately showed that my root file system only had 23.8G out of 26G in use, leaving insufficient space for downloading all the packages for the system updates.

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            2.9G     0  2.9G   0% /dev
tmpfs           586M  8.5M  577M   2% /run
/dev/sda6        26G  23.8G 2.2G  92% /
tmpfs           2.9G   45M  2.9G   2% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           2.9G     0  2.9G   0% /sys/fs/cgroup
/dev/sda2       256M   56M  201M  22% /boot/efi
/dev/sda8       157G   58G   91G  39% /home
tmpfs           586M   12K  586M   1% /run/user/1000

The du utility estimates file space usage by specific files or directories, and I used the following command to check what the top consumers of disk space were within /var, since I needed more space for /var/cache/apt/archives/.

$ sudo du -h --max-depth=1 /var | sort -h | tail -n 10
[sudo] password for mark:
4.0K  /var/local
4.0K  /var/opt
1.4M  /var/mail
1.9M  /var/spool
12M /var/tmp
16M /var/backups
20M /var/log
1020M /var/cache
14.7G /var/lib
15.7G /var

/var/lib is the clear outlier, taking up almost all of the space in /var.

By rerunning the command on /var/lib instead of /var, we can check for the top consumers within that directory.

$ sudo du -h --max-depth=1 /var/lib | sort -h | tail -n 10
4.1M  /var/lib/aspell
8.3M  /var/lib/gems
8.5M  /var/lib/tor
8.7M  /var/lib/texmf
17M /var/lib/aptitude
26M /var/lib/mlocate
38M /var/lib/postgresql
85M /var/lib/dpkg
130M  /var/lib/apt
14.4G /var/lib/docker
14.7  /var/lib

Bingo. Docker was eating up all my root disk space, likely through a combination of program files and docker images.

Uninstalling docker

I was fine with purging my system of docker since I wasn’t actively using it and could bring it back later, and this AskUbuntu post was helpful for collecting the steps to completely uninstall it.

sudo apt-get purge -y docker*
sudo apt-get autoremove -y --purge docker*
sudo rm -rf /var/lib/docker /etc/docker
sudo rm /etc/apparmor.d/docker
sudo groupdel docker
sudo rm -rf /var/run/docker.sock
sudo rm /usr/local/bin/docker-compose

Verifying success

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            2.9G     0  2.9G   0% /dev
tmpfs           586M  8.5M  577M   2% /run
/dev/sda6        26G  9.4G   15G  39% /
tmpfs           2.9G   45M  2.9G   2% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           2.9G     0  2.9G   0% /sys/fs/cgroup
/dev/sda2       256M   56M  201M  22% /boot/efi
/dev/sda8       157G   58G   91G  39% /home
tmpfs           586M   12K  586M   1% /run/user/1000

Excellent, we’re back down to just using 9.4G out of 26G of the root file system.

After this I was able to continue the steps from Debian upgrade guide to complete the upgrades without issues.

References