Low disk space - how to clean out garbage?

Hardware Librem 5
45

Ah, okay. Thanks.
Just checking whether it was the same journal cleaning instruction I had seen before, or another one. It’s the same.

And the cache in the flatpak dir is empty.

46

Hello:

To follow up on this:

  1. Can somebody please help us poor souls who have Librem 5 and want to install Flatpaks without unecessary bloat? I realize Purism has other things to do, but this is a silly issue.

  2. Doing things on my own, again, I took a whim and used this command:

rm -r /var/lib/flatpak/appstream/flathub/aarch64

That deleted the whole directory and files in it. I got rid of about 2 GB of what appear to be unnecessary bloat.

Warning, I am a novice and I guarantee nothing! Run that command at your own risk.

I hope that helps someone. There have been no adverse effects on my us of Flatpak apps on the phone - yet.

47

I just reflash the latest Evergreen LUKS and DAS U-Boot images to deal with bloat or misconfigurations. Far more often I do it due to the latter than the former, since I hardly install anything to begin with.

48

Ok. Thank you. Can you make it easy on me and tell me how to easily do that?

1 Like
49

The following official documentation may get you pointed in the right direction: https://docs.puri.sm/Librem_5/Troubleshooting/Reflashing.html

3 Likes
50

Here is a high-level overview:

  1. Download, verify, and install the PureOS 10.3 image on a USB drive using disk-writing software such as balenaEtcher.

  2. Boot into the PureOS USB live image.

  3. Follow the instructions listed by Irvine Wade above this post, or alternatively this one below.

3 Likes
51

See flatsweep (use on own risk).

4 Likes
52

You just saved me 1.6 GB of space. Merci beaucoup!

2 Likes
53

I took the risk and did:
sudo rm -rf /var/lib/flatpak/appstream
This resulted in 4.3GB of extra storage. I did not notice any negative side effects, but use at own risk.
The growing /var/lib/flatpak/appstream is a bug that is fixed in a newer flatpak release.

1 Like
54

Doing a sudo rm -r .* in var/lib/flatpak/appstream/flathub/aarch64 works too, and it is somewhat less drastic.

6 Likes
55

Well done! Bought me three to four times more than vacuum.

2 Likes
56

I have just found out that, to clean up unused files and prevent Flatpak’s footprint from filling up all available space, I need to run regularly something along the following lines.

$ flatpak update
$ flatpak remove --unused --delete-data
$ rm -r ~/.local/share/flatpak/appstream/*
$ sudo rm -r /var/lib/flatpak/appstream/*
$ sudo flatpak repair
$ flatpak --user repair

As far as I understand, It is necessary to delete the contents of appstream directories mannually due to a bug in the Byzantium version of Flatpak, which was fixed upstream. So, it is hopefully not required on Crimson.

Running “repair” is necessary to prune unused binaries in the objects store. I assume that Flatpak has a legitimate reason to keep those files. So, “repair” needs to be run regularly to remove them. But are the relatively unsophisticated users of Librem 5 supposed to know about that? Shouldn’t the PureOS distribution take out the trash for them? What am I missing?

6 Likes
57

Probably, yes, but it doesn’t as such know what flatpak even does - so perhaps installing flatpak should provide that automatic cleanup.

1 Like
58

If it were me who installed the flatpak package on a 31 GB partition, I probably wouldn’t suggest that PureOS should take care of that. However, this is something I would expect Debian to take care of. And it comes pre-installed. Several librem5-* and pureos-* metapackages directly or indirectly depend on it. Flatpak runs on different systems and has various applications. I assume that there may be a valid reason to do not prune the object store for something and keep them for history. Of course, the Purism team could probably work with upstream to convince them, or modify the local version, but it would be unnessary if it is possible to include appropriate maintenance scripts in one of those librem5-* or pureos-* packages that are not metapackages.

2 Likes
59

It is still installed and it should still take care of its own cleanup.

If there’s a good reason not to clean up in some circumstances, it should still give the user configuration options that would nevertheless clean up.

Maybe their design assumption is that everyone has an approx. 256GB disk (or larger), so cleanup is not a priority.

1 Like
60

:+1:

Thank you.

1 Like
61

I think this is a generic “Linux” problem. I see the same problem with snaps under Ubuntu.

If software is installed with apt then everything works well.

If software is installed within some other framework (whether flatpak or snap) then things just never quite work as nicely. The level of integration just isn’t there. It is easy to see how both political issues and technical issues could get in the way.

Maybe it will improve marginally when we all get to crimson.

1 Like
62

thanks for posting these steps. I tried them on a desktop install of PureOS 11, but it didn’t resolve my own issue of 11GB of files in /var/lib/flatpak/repo/objects that I’m trying to slim down.

Going to go scorched earth and remove all flatpak apps and then remove and reinstall flatpak.

For those of you looking for an easy way to backup and reinstall your flatpak apps, try this

flatpak list --app --columns=origin --columns=application | \
awk '{print "flatpak install " $1,$2 " -y"}' > flatpaks.sh; \
chmod +x flatpaks.sh

Run flatpaks.sh created above to reinstall.

3 Likes
63

I think that newer flatpak versions clean up stuff way better. With a future new PureOS release we will probably get a newer flatpak as well.

2 Likes
64

Hope so. This experience has definitely given me pause with my previous “all in on flatpaks” strategy. Always trade-offs I suppose. Flatpaks solved the problem of outdated software that’s so common in versions available from distro packages, unless you run a rolling release distro like Arch or Void.

But that comes at cost of increased bloat and disk space as well as app configuration files buried several levels deep under ~/.var/app/.

2 Likes