7

Still a greenee at Linux as there are so many different approaches/ways to do the same thing. When I attempt to update to Ubuntu 17 I receive:

"The upgrade has aborted. The upgrade needs a total of 317 M free space on disk '/var'. Please free at least an additional 55.4 M of disk space on '/var'. Empty your trash and remove temporary packages of former installations using 'sudo apt-get clean'."

How can I safely reduce the size of this directory?

Filesystem             Size  Used Avail Use% Mounted on
udev                   2.0G     0  2.0G   0% /dev
tmpfs                  396M  6.0M  390M   2% /run
/dev/sda1              9.1G  2.8G  5.9G  32% /
tmpfs                  2.0G     0  2.0G   0% /dev/shm
tmpfs                  5.0M     0  5.0M   0% /run/lock
tmpfs                  2.0G     0  2.0G   0% /sys/fs/cgroup
/dev/sda5              9.1G  824M  7.8G  10% /home
/dev/sda7              922M  612M  248M  72% /var
/dev/sda11             922M  1.2M  858M   1% /run/shm
/dev/sda8              922M   21M  839M   3% /var/log
/dev/sda10             226M  2.1M  208M   1% /var/tmp
/dev/sda6              923M  8.5M  851M   1% /tmp
/dev/sda9              922M  8.7M  850M   2% /var/log/audit
//10.2.222.31/DOCMgmt  500G  216G  285G  44% /mnt/win1/DocMgmt
//10.2.222.31/LOGS     250G   89G  162G  36% /media/logs
tmpfs                  396M     0  396M   0% /run/user/1000
3
  • Please first run sudo apt autoremove then try again Jul 11, 2017 at 20:48
  • Autoremove was executed prior to attempting the update.
    – Micdarj
    Jul 11, 2017 at 21:27
  • $ sudo apt autoremove Reading package lists... Error! E: Could not create temporary file for /var/cache/apt/srcpkgcache.bin - mkstemp (28: No space left on device) What do you do when there's not enough space for autoremove?
    – Zim
    Apr 6, 2020 at 23:27

1 Answer 1

3

The easiest way to quickly find large, unneeded candidates that can safely be removed is

cd /var

du -k

This will list the amount of space being consumed in each /var subdirectory.

In your case, you have created partitions for "the most likely suspects". /var/log, /var/tmp and so on.

At 248M you have quite a lot of free space on /var, just not enough for this particular update. If you do updates more frequently the amount of space needed in /var should be less helping you to avoid this problem moving forward. More frequent updating will also help you keep things secure by applying patches for newly discovered vulnerabilities.

In your situation, I'd be looking for a massive core dump file or a runaway log file. Focus first on any subdirectory that has a big number associated with it's content, like

/var/crash

/var/cache

Then see if there are any big files in them that can be safety removed.

1
  • 1
    du -h /var | sort -hr | head -n10 for better visualisation and folder based comparison Oct 5, 2022 at 8:06

You must log in to answer this question.

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