Looking for creative ways to reduce disk space occupied by system folders

[lads]

Hi all. I am in the process of upgrading all my systems to 20.04. Some days ago I noticed that in one system the 22 GB allocated to / where nearly full. I then performed the usual tasks:

1. Removed old kernels (only one was around).
2. Purged the package cache with apt.
3. Removed all orphaned packages found with gtkorphan.
4. Uninstalled about a dozen applications used less frequently.
5. Removed older versions of Snap applications.
6. Cleared systemd journal logs.

All this freed about 2 GB, which is still insufficient to upgrade to 20.04. A fresh Ubuntu installation should not take more the 5 GB, and while I have various programmes installed, I am at a loss to explain how it can take up so much space.

The problem is that there is no obvious culprit. Listing the packages larger than 100 MB, I can see TexLive is taking some space, but far from justifying 20 GB:

dpkg-query -W -f='${Installed-Size;8}  ${Package}\n' | sort -n
[...]
  105934  texlive-fonts-extra-doc
  106874  docker-ce
  115945  libboost1.65-dev
  125423  inkscape
  132095  libreoffice-core
  165607  linux-modules-extra-4.15.0-91-generic
  165744  linux-modules-extra-4.15.0-108-generic
  165765  linux-modules-extra-4.15.0-109-generic
  178737  docker-ce-cli
  206344  firefox
  214194  chromium-browser
  232263  libgl1-mesa-dri
  232770  skypeforlinux
  324978  linux-firmware
  909313  texlive-fonts-extra

Also ranking system folders nothing obvious comes up:

$ sudo du -h --max-depth=0 bd bin boot cdrom data dev etc lib lib32 lib64 lost+found opt proc root sbin snap srv sys tmp usr var | sort -n -r
206M	boot
188K	tmp
66M	root
20M	etc
16K	lost+found
13M	sbin
13M	bin
12K	dev
11G	usr
8,0K	data
5,8M	lib32
4,0K	srv
4,0K	lib64
4,0K	cdrom
4,0K	bd
4,0G	snap
3,3G	var
3,1G	opt
1,1G	lib
0	sys
0	proc

$ sudo du -h --max-depth=1 /usr | sort -n -r
809M	/usr/bin
684K	/usr/games
404M	/usr/src
240M	/usr/include
91M	/usr/libexec
20M	/usr/sbin
11G	/usr
8,0M	/usr/lib32
4,2G	/usr/lib
4,1G	/usr/share
1,1G	/usr/local

I would welcome creative ideas to further reduce space that do not involve randomly uninstalling software.

Thank you.

[dragonfly41]

Stacer provides a nice dashboard to optimise resources.
You appear to have a lot (4GB) of snap installations. Start there.
The Stacer dashboard has an Uninstaller dashboard.
Look at snap packages installed.

[SeijiSensei]

You might have some old log files in /var/log you can remove.

[Impavidus]

You've got 11GB in /usr, which is reasonable if you've installed a bunch of applications. 1GB of that is in /usr/local, which must be manually installed software. 3GB in /var is a bit much, but not excessive. Maybe you can clean up some more old logs. 3GB is in /opt, which I guess are applications you didn't get from the official repos. It's quite a lot; I guess there's a big application there with a lot of data. 4GB is in /snap, so some room for cleanup there. Snap packages are big and new versions get installed automatically, all by design, so that quickly adds up. I haven't got any snaps on my system. They don't get installed out of the box on Xubuntu and I like to keep it like that. Together that accounts for most of your 22GB.

Edit: snaps are on a different filesystem, so they don't count to your 22GB.

[TheFu]

swap file?

To find unused snaps use,

$ snap list --all|grep disabled
lxd     4.3       15913  latest/stable  canonical*  disabled
scrcpy  v1.14     230    latest/stable  sisco311    disabled
snapd   2.45      7777   latest/stable  canonical*  snapd,disabled

The disabled versions have new versions installed. Sadly, there isn't 1 command to clean those up and we have to use the "ver" in the snap remove --revision command.

i've been meaning to write a little script for that.

[deadflowr]

i've been meaning to write a little script for that.

Here:

!/bin/sh
set -eu

snap list --all | awk '/disabled/{print $1, $3}' |
    while read snapname revision; do
        snap remove "$snapname" --revision="$revision"
    done

from here:
https://superuser.com/a/1330590
Must run as root (sudo)

For the record snaps take no actual physical disk space in /snap.
The disk space use for snaps is in /var/lib/snapd/snaps.
The space shown in /snap is just the mountpoint for the squashfs in the /var location.
Which is how you (or I in my own case) can see 50Gb of spaced used on a 40Gb partition.
More here: https://askubuntu.com/a/1000200

[TheFu]

Thanks. i prefer to have scripts that depend on sudo generate the commands, not actually perform them.

#!/bin/sh
set -eu

snap list --all | awk '/disabled/{print $1, $3}' |
    while read snapname revision; do
       echo   sudo snap remove "$snapname" --revision="$revision"
    done

generated this:

sudo snap remove lxd --revision=15913
sudo snap remove scrcpy --revision=230
sudo snap remove snapd --revision=7777

[sudodus]

Thanks for this script

[kneutron]

> All this freed about 2 GB, which is still insufficient to upgrade to 20.04

--You have a couple of options. One is to add another disk, whether USB3 or internal SATA and create a 10GB ext4 or XFS filesytem on a partition on that disk. ' gparted ' can help you with this. Don't use the entire drive space in case you want to create more partitions on it.

o Then mount it somewhere and move everything as root (I would recommend using Midnight Commander 'mc') in /var/cache to that partition.

o Then mount that partition as /var/cache, or symlink a pointer to your existing mountpoint: ' ln -sfn /mnt/yourseconddrive /var/cache ' -- that will give you enough space to download .deb packages into /var/cache.

o Don't forget to modify /etc/fstab to have it mount after every reboot, and you may have to delete the existing /var/cache dir first after moving files out of it if 'ln' gives you an error. Also note you will need to leave this drive attached in order to boot and work correctly in the future, unless you move /var/cache back to where it used to be.

--You can use similar procedure to move other directories to separate partitions, such as /home. This will free up quite a bit of space on your root filesystem.

--You could resize partitions on your existing disk, but you would definitely need to back things up to another disk anyhow before modifying things in place.

--You could consider redoing everything with LVM, but I would avoid that as for some it becomes difficult to manage, slows things down and I consider it in general more painful than helpful.

--Another option would be to do a fresh install of 20.04 to a USB3 drive, which would give you portability and a chance to redo your partition scheme with larger sizes, or do an experimental install to ZFS boot/root (requires UEFI.) And you could copy your files off the old install. If you go this route I would recommend using a USB3 portable SSD such as the Samsung T5 (rather than a thumbdrive.)

[GhX6GZMB]

Why do you have 3.1G in /opt? These days it's normally empty. Special programs? And the 3.3G in /var makes me suspect you have enormous logfiles lying around.