If there are only some significant fixes it means that this issue will remain and switching between WiFi and Cellular will still not work as expected for Android apps. 
I’d rather consider fixing this bug significant - and not fixing it not significant…
Let’s hope and see:-)
1 Like
I guess you work about the root partition space needed to perform an upgrade.
This is an arbitrary limit determined empirically. It is set to ensure free space remains abundant during the upgrade install. I think it is not linked directly to the size of the upgrade which is downloaded to the user partition anyway.
I have face the same issue with the recent update. Luckily I remembered I installed caligraconv just recently. Removing (whole) calligra and a couple of log files (upgrade log) got me back to have just a bit over 500MB of root free space. The upgrade completed without an issue.
Still I’m wondering what I have installed that consumes all the root partition space (btw. I’m on Xperia X).
I never had problems related to the size when updating via CLI.
1 Like
Upgrading via the CLI is not for the faint at heart. I prefer the GUI.
1 Like
Maybe one should increase the size of rootfs (at the cost of some /home space)? Are there any problems / disadvantages with doing so? How about 4 GB of rootfs? It wouldn’t hurt free space left on home partition too much.
Well, using the GUI I had repeatedly problems (i.e. failed updates that had to be repeated, boot-loops, etc.), whereas via CLI never. Just issue both commands and that’s it 
OK, if the GUI reports an available update, I can ‘not start’ the update via GUI. That I understand.
But after this, what have I to do to start the update via CLI? I want to try this at next update time.
99% certainty it’s an illusion, just “reboot freshness”.
1 Like
Just to be sure, the size requirement for sfos-upgrade is exactly the same as for the GUI.
1 Like
It would indeed be nice if L10N files would be split out of the relevant packages. That would save (if unwanted languages are uninstalled) about 100MB on the root fs.
1 Like
Yes. Another solution, perhaps, might be to port Debian’s localepurge script to SFOS. Localepurge has been ported to Arch Linux. It is in the user repository (git clone https://aur.archlinux.org/localepurge.git). I thought maybe this version would be a good starting point for a port to SFOS if anyone could be interested in undertaking this task?
Last update had problems with camera/flashlight but this worked perfectly (XA2). After 4.4.0 I will buy license for my phone.
With 4.3.0.15 on Xperia 10 still problems with Advanced Camera. Main camera + flash worked exactly one time after installing and never again. Selfie camera works fine.
Jolla camera: both cameras working fine.
1 Like
I’m quite happy with gphoto for Android which I found including some Xperia specific configs in the XDA developer forum.
Only a week ago I’ve had over 900 MB of free space on the rootfs. Now I have 750 MB and I wonder where did nearly 200 MB go. The only important thing that I did in the meantime was appying the 4.3.0.15 OS update. Did it eat 200 MB or what? Where should I look and what to check?
Maybe /var/cache?
Could be the updated rpms are still there.
Answer seems obvious, don’t lough at me, but I don’t find: is there a changelog or alike to see what has been modified in the 4.3.0.15 update?