Trying to update my X to 3.0.2.8 which has just become available, the pretty updater failed as usual but today the script is also unhappy due to low space. Is 1.2GB really not enough? It's 50% of the root partition so sounds like it should be...

For me 550 MB were enough. Had no bigger problems using sfos-upgrade from openrepos:
https://openrepos.net/content/olf/sfos-upgrade

Thanks - that's the script which suggested I should have 1.5Gb free. I will ignore it and proceed

I assume you are using an ancient version before v1.2 then.
If so, please update sfos-upgrade first, before upgrading SailfishOS with it.

The current (since v1.2) hard free space limit for non-BTRFS root filesystems is 0,5 GB, which is pretty tight when performing an upgrade to a different version than the directly following one (even might be too tight then).
That is the reason why a warning is shown when below 0.75 GB free space on a non-BTRFS root filesystem.

Had to deinstall about 200MB of applications and UI was happy enough to start the already downloaded update.
It went through having the status bar filled up to 100%. And then ...
...
...
Silence!
Pushed the power button and saw very briefly something with warning
but fortunately device booted and said old version is running.
So I started the download again (missing 2MB !!!), took some seconds and I was allowed to start the update again.
This time everything went smooth and I am on 3.2.0.8.

Wjat I am doing after an upgrade is:
version --dup
to check/get really everything. And one/two packages were loaded/installed (forgot already ).
Then enable my openrepos and another
version --dup
which loads a lot of stuff, also some system stuff (tar, wget, ...)
And fix some workarounds (ping - this time not needed?, fingerterm flashing, vpnc,...)
And sync, reboot.

...or using a thin pool, if you want to share more potential space between the two ext4 partition on the LVM.

Meaning that no matter what solution was taken, the low available space on older smartphones such as the Jolla1 *is* going to bite the users, no matter what solution Jolla went for back then.

The only difference is the familiarity of power-users when encountering the symptoms and the familiarity of the procedure to get around it :

- running low on normal EXT4 partition above LVM is about the least surprising condition, and is solved by the most straight-forward solution (freeing space by deleting stuff from the partition that got filled up). The only surprising part being *what* is stored onto which partition (android layer mount-binds stuff from home, so deleting apps *from android* will not necessarily free space from root).

- running low on EXT4 over a thinpool would have been a little bit less straight forward (the partition still reports free virtual space, but the thin pool has ran out of provision to assign to this space, so you get error while trying to write files, even if the partition says other wise). That's probably while Jolla has picked the small rootfs instead of fumbling around thinpools: they have been bitten enough by BTRFS and wanted a more straigh forward and simple handling of space.
(Though a GUI reporting the remainning space on the thin pool, instead of simply the partition free space would have helped).
Procedure gets a tiny bit less straight forward: you need to delete stuff (from whichever partition you want, even the wrong one) and then run TIRM / DISCARD on the claimed space to return it back into the thinpool.
(tough some modern filesystems try to auto-trim under some circumstance like freeing large extents. Sailfish X does it).

- running low on available chunks to allocate on BTRFS is about the weirdest, because the filesystem might need to allocate chunks for CoW - overwriting a file *will* consume extra space even if transiently. Or the filesystem might need more chunks for metadata, be unable to allocate one extra and complain even if there is still plenty of free space on the data chunks and thus the partition seeming free.
The procedure isn't also always straight forward, with re-balancing being needed to free chunks which can then be re-allocated in turn.
Or needing to add extra space by adding SDcard partitions to the BTRFS filesystem.

Though modern BTRFS drivers in recent kernel have dramatically simplified this: "free space" now takes into account chunks (but then gives rise to other situations where *deleting stuff* will *decrease* the free space) and auto-balancing helps somewhat.
(My Rasbperry Pi running up-to-date 4.xx kernels has a lot less (=none) problems with BTRFS than Sailfish OS used to have on Jolla 1)




But in the end, the limited space is problematic for Sailfish, not the BTRFS vs LVM vs thinpool solution.

(Never had a problem with my BTRFS uSD card even back on Jolla1. But that one had a tad bit more space...)


The only slightly better solution would have been adding the phone's "Android System" partition to the LVM volume group (in linear mode) which would have added more headroom. But then in turn would have removed the simple factory reset mecanism (plain partition image laying on a plain Android System partition) and put a rather complex one (needing to handle the reset from within LVM itself, meaning that a corrupted LVM will break the reset. See BTRFS snapshot based recovery and corrupted BTRFS problems for an example).

The current "next best" solution, it to get help from a IT geek, and repartition the space differently between the "Android System" and "Data partition", as usually 7G or more are reserved for Android, but recovery only needs about <1G out of that.
Makes it harder to flashback to Android (e.g.: for Warranty handling), but at least you get a bit more free space to play with.

As an alternative, if you look on GitHub (and or Mozilla forum) there are dozens of tools written in Python or Node.js that can assist you for that.
(Random example)

Or Javascript that you can run on the browser it self (see here and here). Though I have tested these only on desktop firefox (easier when you have a real-world debug console) rather than embed (where you could need to write the script into files and find a way to invoke them with the necessary privileges).

I use LVM a lot & help to develop and maintain an OS installer (Anaconda, used in Fedora & RHEL) that always installs to LVM by default. Over the years I don't remember a single case where users would report their storage being hosed due to the LVM layout/metadata being corrupted. It has always been either hardware failure or storage configuration tools (including the ones we have in the installer :P) doing something the wrong way.

Therefore I think Jolla is being overly defensive in this case when the insist on re-creating the LVM layout every time during factory reset.

Having two physical volumes (PVs) on the two big partitions, putting them into a volume group (VG) and then creating all the logical volumes (LVs) from the VG should be safe.

For example on my Xperia X, there is a 20.7 GB partition used for LVM and a 7.3 GB partition used for the firmware images (with about 300 GB space used, wasting almost full 7 GB of space).

Say we create two PVs, one on the 20.7 GB partition and one on the 7.3 GB one, giving us 28 GB of space in the VG. From that we create a 1 GB firmware image LV, a 5 GB root LV and 22 GB home LV. That should give plenty of space for all uses when we are no longer wasting a full 7 GB for nothing.

Then when you do a factory reset, simply run mkfs.ext4 on the root & home LVs and dump content of the respective firmware restore tarballs. If you want to be really through you might want to call wipefs on the LVs first or even re-create the root and home LVs in the VG. But really, there is no good reason to drop the full LVM layout and re-create it every time.

From what I've heard so far (and anyone more knowledgeable is free to correct me), touching the partition layout on an Android device is very dangerous. Apparently some of the early boot and baseband stuff is fetching it's firmware and configs from specific byte offset. Changing the partition layout then could change those offsets, breaking these sub systems or possibly even bricking the device.

does anyone know a way to upgrade android binaries to 17B without needing to re-flash SFOS?

Here you go. (I̶ ̶h̶a̶v̶e̶n̶'̶t̶ ̶t̶r̶i̶e̶d̶ ̶t̶h̶i̶s̶ ̶y̶e̶t̶ Just did this, so far so good.)

Edit: I did had to reset the camera's app settings, as its configuration got lost or something. Settings → Apps → Camera.