to get more space on the system partition, you need to delete applications (HERE Maps etc) …
This is a long time known and pushed away shortcoming that the root partition is way bto small.
We collected some links and especially this one here
https://together.jolla.com/question/222126/guide-installing-sailfish-x-on-xperias/#222126-33-increasing-the-root-lvm-volume-size
is a need to do for every one installing a bit more native applications.
Android apps are installed to home so will not help umstalling.
Try to drill down with e.g.
du -xsh /
where the real big data chunks are and go deeper and deeper.
I jad that earlier with JollaC and needed to uninstall lots of native packages i.e. big data apps like OSM scout or similar
…
Find out with e.g.
rpm -qa --queryformat '%{SIZE} %{NAME} \n' | sort -n -r | head -10
3 Likes
thanks this I was afraid to do looked a bit risky for me but I will do it now.
Nevertheless I tried to delete many apps and finally had enough space to update which was even quite fast done.
But the volume size should be at least 4 GB min by default I would say.
On Xperias this may work without any issue (even with more data on partitions, but I did it right after flashing!).
Yes, 4GB is a good start value for root partition. Now having 2.7/3.9 used. Of course this limits the available space for home partition for Downloads and Pictures/Videos.
But better than not being able to update!
Many peeps (me included a few times) suffered from this but it seems no one from the Sailors…
This was told so many times and so long ago to Jolla, but no reaction. 
1 Like
Major issue is that apps are installed on the system partition. They should be installed in the home.
Problem is now developing a link or overlay system that bind mounts the applications installed to the right location.
Thats something that will take a lot of work as apps are system installed always one user cannot have apps installed that the other does not.
In other words. Its a complicated mess.
1 Like
Similar the mess as on N900 with its tiny rootfs? 
But there we had /opt where lot of application data went, iirc?
But for the time being (soon™ ) the root partition layout could be a simple parameter to the flashing file to define rootfs size (default 4G)?
Another huge waste of disk space is the installation of all available locales. On desktop distributions there are tools to cleanup / remove unused locales. I haven’t found any on Sailfish OS. For the update from 3.4 to 4.0.1.15 I removed many locales manually, which was a pain.
They were back after the installation of 4.0.1.15.
I just flashed Sailfish 4 this week. To prevent problems in the future, like this lack of space, I’m considering following the guide in the link you left here.
But I have a concern: do these old instructions still apply to the current version?
Yes they do, go for it. I have extended my root partition in the past and it is completely safe as long as you follow the steps and make sure you type (or copy&paste) everything correctly. And since you just flashed your phone this week, in the worst possible situation you don’t lose years worth of your data if you mistype something critical and need a reflash (still remember to take backup before doing this).
If you have a device with system_a and system_b labled partitions, you can use the free space on system_a to extend the rootfs. Extend SailfishOS rootfs with a hidden, unused partition.-Oskar Roesler's Blog
4 Likes
Great finding!
You mention in your blog that after adding system_a to logical volume group we cannot reflash SailfishOS without reflashing Android first. Does that also apply to SFOS Updates?
What’s the original usage of system_a?
What data is on it before adding it to SFOS root partition?
Having A/B partitions implies to me that it’s a fallback partion of booting from the primary partition fails.
Wouldn’t it be an option to backup the image of system_a before the modification and in case we want to revert, we go into rescue mode, remove system_a from LVM and restore the backup?
1 Like
Cool that someone likes my 1st blogpost that I’ve actually published and doesn’t lie half-finished around.
Of course not, I’ll update the blogpost to clarify this better.
system_a and b are used by Android to install OS updates. If a is used, the new os is written to b and then b gets used after restart. Next time the other way around.
Doesn’t really make sense to me. To flash back the original content to system_a, you would have to
- Free space in root until you have less than 2.5Gb used space (like before extending)
- Defragment and shrink the rootfs and shrink the root volume.
- Remove system_a from the volume group.
- Flash back system_a content.
- No with your Sailfish reflash, you overwrite anything anyway.
Additionally, while shrinking there’s much more to go wrong. Installing Android and then Sailfish again is just guaranteed to work. I can case you really ever need to reflash your devices. Happened to me only once that the update fucked up the system entirely. But theoretically, you could do this.
3 Likes
But that also means it is not always system_a that is unused. Depending on how many upgrades the device did, it might be system_b, right?
vendor_a and vendor_b (and oem) are also 850M, maybe one of these could be removed as well?
1 Like
Interestingly system_a seems to contain the android image and according to /system/build.prop it is 50.2.A.3.77. system_b contains SailfishOS3.4, which should be the sfos version I originally used to flash the device.
But system_b looks drastically different from system_a:
# ls /tmp/sysb/Sailfish_OS-Jolla-3.4.0.24-h3113-0.0.7.52/
home.img.gz home.img.gz.md5 root.img.gz root.img.gz.md5
1 Like
Once again, thanks for your nice guide!
Just extended my root partition by system_a as you described.
I think it’s worth mentioning that you get messages such as /dev/mmcblk0rpmb: read failed after 0 of 4096 at 4186112: Input/output error. Anyways, each step was confirmed with a positive status message in the end. So I ignored those input/output errors and everything worked fine (so far).
[nemo@xa2 ~]$ df -h
Filesystem Size Used Available Use% Mounted on
/dev/sailfish/root 5.2G 1.9G 3.3G 36% /
1 Like
I had to look up what rpmb stands for because I can’t remember getting this error and that device isn’t just called /dev/mmcblk0 as normal was weird me. According to the internet, it is the Replay Protected Memory Block, a security storage from Android. So it’s obvious and nothing to worry about that when the programs try to scan all partittions, the read for this one fails. I’ll add it to my blogpost.
Yes they do, but the canonical link for my Guide: Installing SailfishX on Xperias and its section 3.3 Increasing the “root” LVM volume size is at olf / SailfishX on Xperias · GitLab
These instructions are regularly updated there.
2 Likes
I’ve moved this topic into the General section, since I didn’t want to close it for not being a bug (there’s lots of nice and useful discussion here). If anyone disagrees with this move, or thinks some other category would be more appropriate, please let me know.
1 Like
It already does since 2020 and is set to 4GB on the Xperia 10 and newer models. “Use the force, read the source”, but it is implemented a bit convoluted (try to find the place where this is set dependent on the device model ).