I had the same problem on JollaC with the last update (2.0.5) - had to remove almost all apps (including AlienDalvik) to be able to proceed. As each update is bigger and bigger, this is bound to get worse over time.

I haven't seen any reports of this kind on TJC, but I will report it if it happens with this update as well.

I used to have issues on the original Jolla phone (with is notorious for its BTRFS balancing issues), but I haven't had it on the JollaC. I now use an sd card, and make sure that the camera stores pics in there, and have also moved any docs over.

Some general housekeeping like deleting browser cache (and maybe from some android apps too) might help to.

Code:

du -h --max-depth=1 | grep M

will give you the disk usage of each directory in the current location, and is a good starter for tracking down the guilty apps.

On my desktop PC a program called Acestream had gigabytes locked up in useless cache files.

I used to have issues on the original Jolla phone (with is notorious for its BTRFS balancing issues), but I haven't had it on the JollaC. I now use an sd card, and make sure that the camera stores pics in there, and have also moved any docs over.

Some general housekeeping like deleting browser cache (and maybe from some android apps too) might help to.

Code:

du -h --max-depth=1 | grep M

will give you the disk usage of each directory in the current location, and is a good starter for tracking down the guilty apps.

On my desktop PC a program called Acestream had gigabytes locked up in useless cache files.

The problem is that both user data (pics, browser cache) and Android apps are on different partitions than the one we have problem with.
I have 4.5GB free space on /home/nemo and also deleting Android apps has no effect on the system partition (where I had ~300MB of space available before this update). I had to delete Kodi, /opt/sdk and AlienDalvik this time in order to get to the required 500MB of free space.
Of course, there could be some logs taking space, but needless to say, whatever you do with it, ~2.5GB for the system partition is far too small.

__________________I don't understand why would anyone use a random, insecure, proprietary chatting solution as WhatsApp, when you have so many safe and open alternatives.
Please, don't use it. If this doesn't convince you, read more here.
The worst thing is even if you don't use it, it takes one ***** who does and has your number in his/her contacts and your number is uploaded to servers of this insane company for 'anyone interested' to read.
Thumbs up for everyone supporting WhatsApp on Maemo. NOT

I somehow managed to check for updates again by deleting ~/.cache/store-client/os-info and pkilling store-client, and now the update is downloading! I didn't get the 500MB warning again, even though nothing changed and there is still less than 500MB available in the system partition. Either way, even if this works around the issue, it isn't solved yet because with a couple of big applications and logs here and there, it's immediately full.

Well, the system and data partitions are LVM Logical Volumes formatted with EXT4. As EXT4 can be both shrunk and grown, it shoulw be possible to first shrink the data LV filesystem, then shrink it's LV to free up space in the Volume Group (the volume group is full by default). Then just make the system LV bigger and grow it's filesystem.

The only issues should be that while you can grow a mounted EXT4 filesystem, you can only shrink an EXT4 filesystem that is not mounted. So it would have to be done from a recovery shell or something similar.

Another possibility might be to create another Physical Volume on a uSD card partition and add it to the VG, to add more space. Then resize the system LV and then grow it filesystem. But note that by this the uSD card basically becomes part of the - part of the system partition data will be located on it and the device might not boot if it can't find the card at boot time (or if the card dies). Or it might not boot anyway if for example the card shows up much later than the internal storage during boot or if the initrd has some issues finding the PV on the card during boot.

The shrink-data LV, grow-system LV method should be definitely the safer one. And still always backup first before attempting anything like this!

Mmm. Updated without issues. Everything seems to run much faster. Including the battery. Starting from about 84%; this jumped to 100% after the reboot. Now, less than 30 minutes after the update, I am down to 47%.

__________________In particle accelerators atoms are indeed not only touching each others. But banging together in a massive explosive orgasm.
-- nieldk in a TMO post