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
The easiest way to quickly find large, unneeded candidates that can safely be removed is
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
Then see if there are any big files in them that can be safety removed.