More space for /home or /root with mininal effort

Taking advantage of the super partition

Every Android system has a super partition, which is dedicated to saving the Android OTA (system updates), and AFAIK, that partition is not used anymore when SailFishOS is installed because even if the Android Support is installed, it does not upgrade the system.

The super partition size depends on the Android system size and not the smartphone model, AFAIK. In my Sony Xperia 10 II, that partition is 12GB and is mapped on:

  • /dev/mmcblk0p85

Your device can be mapped differently, but you can find it using this function:

grnc() { grep --color=never "$@"; }

    local i dev txt d="/sys/class/block"
    test -n "${1:-}" || return 1

    if [ "x${1:-}" = "x--all" ]; then
        for i in $(ls -1  $d/mmcblk*/uevent 2>/dev/null); do
            echo $(grnc -E "DEVNAME|PARTNAME" $i) | grnc -e "DEVNAME.*PARTNAME"
        return 0
    dev=$(grnc -nw PARTNAME="$1" $d/mmcblk*/uevent 2>/dev/null | cut -d: -f1)
    echo "$dev" | wc -l | grnc -wq 1 || return 1
    test -n "$dev" || return 1
    echo /dev/$(basename $(dirname "$dev"))

In this way:

  • mmcblk_findby_label super

There is also a SFOS script that contains something similar to the function above, but it is way slower, which is why I developed that function.

The way to add that space to your system can vary depending on your needs, like increasing your user space, increasing the root size, or using it to store a toolchain for compiling natively applications on the smartphone directly.

Adding 12GB can make a tiny or big difference, depending on your needs. If your userspace is running out, 12GB more will give you a breather. If you need to install a toolchain or something like that, considering that the root size is 5GB, adding 12GB is a great help.

Like everything is SFOS, this suggestion is AS-IS without even the bare knowledge of the consequences or the corner cases, for the most basic reason: I do not use SFOS but RFOS. Consequences might vary from “nothing bad but good only” to “immediate universe collapse” or something in between, which explains why nobody before noticed that, but @olf documented a complex procedure to change the LVM partition sizes in order to increase the root space.

mkfs.ext4 -m 0 /dev/mmcblk0p85
mkdir -p /usr/local/extraspace
mount  /dev/mmcblk0p85 /usr/local/extraspace

To use it for your user, you need to change the /etc/fstab and tell the system to mount it at boot time, giving that mount point the proper uid and gid for your user. In this case, the natural place for the mount point is the user’s home. Something like /home/defaultuser/superdata.

May the super be with you… :blush:


Hi this sound super interesting.
I tried to find a 12GB partition on my XA2 Ultra phone but seem not to have something when executing lsblk:

mmcblk0 179:0 0 29,1G 0 disk
├─mmcblk0p1 179:1 0 2M 0 part
├─mmcblk0p2 179:2 0 32M 0 part /persist
├─mmcblk0p3 179:3 0 1K 0 part
├─mmcblk0p4 179:4 0 2M 0 part
├─mmcblk0p5 179:5 0 2M 0 part
├─mmcblk0p6 179:6 0 2M 0 part
├─mmcblk0p7 179:7 0 16M 0 part
├─mmcblk0p8 179:8 0 64K 0 part
├─mmcblk0p9 179:9 0 64K 0 part
├─mmcblk0p10 179:10 0 3,5M 0 part
├─mmcblk0p11 179:11 0 3,5M 0 part
├─mmcblk0p12 179:12 0 4M 0 part
├─mmcblk0p13 179:13 0 4M 0 part
├─mmcblk0p14 179:14 0 512K 0 part
├─mmcblk0p15 179:15 0 512K 0 part
├─mmcblk0p16 179:16 0 512K 0 part
├─mmcblk0p17 179:17 0 512K 0 part
├─mmcblk0p18 179:18 0 512K 0 part
├─mmcblk0p19 179:19 0 512K 0 part
├─mmcblk0p20 179:20 0 1M 0 part
├─mmcblk0p21 179:21 0 1M 0 part
├─mmcblk0p22 179:22 0 1M 0 part
├─mmcblk0p23 179:23 0 1M 0 part
├─mmcblk0p24 179:24 0 256K 0 part
├─mmcblk0p25 179:25 0 1M 0 part
├─mmcblk0p26 179:26 0 1M 0 part
├─mmcblk0p27 179:27 0 1M 0 part
├─mmcblk0p28 179:28 0 1M 0 part
├─mmcblk0p29 179:29 0 1M 0 part
├─mmcblk0p30 179:30 0 1M 0 part
├─mmcblk0p31 179:31 0 128K 0 part
├─mmcblk0p32 259:0 0 64M 0 part
├─mmcblk0p33 259:1 0 64M 0 part
├─mmcblk0p34 259:2 0 256K 0 part
├─mmcblk0p35 259:3 0 256K 0 part
├─mmcblk0p36 259:4 0 256K 0 part
├─mmcblk0p37 259:5 0 256K 0 part
├─mmcblk0p38 259:6 0 64M 0 part
├─mmcblk0p39 259:7 0 64M 0 part
├─mmcblk0p40 259:8 0 1M 0 part /bt_firmware
├─mmcblk0p41 259:9 0 1M 0 part
├─mmcblk0p42 259:10 0 110M 0 part /firmware
├─mmcblk0p43 259:11 0 110M 0 part
├─mmcblk0p44 259:12 0 16M 0 part /dsp
├─mmcblk0p45 259:13 0 16M 0 part
├─mmcblk0p46 259:14 0 4M 0 part
├─mmcblk0p47 259:15 0 4M 0 part
├─mmcblk0p48 259:16 0 32M 0 part
├─mmcblk0p49 259:17 0 32M 0 part
├─mmcblk0p50 259:18 0 1M 0 part
├─mmcblk0p51 259:19 0 4K 0 part
├─mmcblk0p52 259:20 0 256K 0 part
├─mmcblk0p53 259:21 0 256K 0 part
├─mmcblk0p54 259:22 0 4K 0 part
├─mmcblk0p55 259:23 0 32,6M 0 part
├─mmcblk0p56 259:24 0 4K 0 part
├─mmcblk0p57 259:25 0 1M 0 part
├─mmcblk0p58 259:26 0 8M 0 part
├─mmcblk0p59 259:27 0 1M 0 part
├─mmcblk0p60 259:28 0 16K 0 part
├─mmcblk0p61 259:29 0 8K 0 part
├─mmcblk0p62 259:30 0 512K 0 part
├─mmcblk0p63 259:31 0 2M 0 part
├─mmcblk0p64 259:32 0 1M 0 part
├─mmcblk0p65 259:33 0 64M 0 part
├─mmcblk0p66 259:34 0 64M 0 part
├─mmcblk0p67 259:35 0 512K 0 part
├─mmcblk0p68 259:36 0 450M 0 part /odm
├─mmcblk0p69 259:37 0 450M 0 part
├─mmcblk0p70 259:38 0 850M 0 part
├─mmcblk0p71 259:39 0 850M 0 part /opt
├─mmcblk0p72 259:40 0 1M 0 part
├─mmcblk0p73 259:41 0 16M 0 part
├─mmcblk0p74 259:42 0 32M 0 part
├─mmcblk0p75 259:43 0 20M 0 part
├─mmcblk0p76 259:44 0 20G 0 part
│ ├─sailfish-root 252:0 0 2,4G 0 lvm /
│ └─sailfish-home 252:1 0 17,6G 0 lvm
│ └─luks-8b643507-73fa-4e6e-b1ce-407a53591a5f 252:2 0 17,6G 0 crypt /home
├─mmcblk0p77 259:45 0 20M 0 part
├─mmcblk0p78 259:46 0 2,8G 0 part
└─mmcblk0p79 259:47 0 2,8G 0 part
mmcblk0rpmb 179:32 0 4M 0 disk
mmcblk1 179:64 0 59,7G 0 disk
└─mmcblk1p1 179:65 0 59,7G 0 part /run/media/nemo/b08d809a-4f97-4eb2-8915-04ad4dae65ed
zram0 253:0 0 512M 0 disk [SWAP]

Is it different on older phones? and why are there so many partitions? What’s the advantage of it?
Since I do not have much experience with scripts… can I just save your function as .sh file and use it or is there more to it?

The partition scheme is taken over from the android installation, most partitions are not used in SFOS. The space you are missing is for the biggest part in these two partitions: ├─mmcblk0p78 259:46 0 2,8G 0 part
└─mmcblk0p79 259:47 0 2,8G 0 part, but also distributed to many medium sized partitions.
After all, the disk of the XA2 Ultra is not that big.
There was a guide either on jolla together or here on how to include some _A partion to the home directory, but I don’t find t anymore.


Vendors that deliver smartphones with limited internal disk space can adopt a customised approach to the standard super partition. Obviously, their choice affects the future OTA capabilities. However, like every vendor’s customization it would be a compromise between available resources and features. They account for it and live with it.

Returning on the main topic: the XA2 Ultra smartphone owners have less disk space to rescue, but in proportion, it is relatively double compared to the internal disk size:

  • 2 x 12GB / 128GB = 5.6GB / 30GB

The bad news is that space is distributed mainly in two partitions, and the good news is that space is distributed in two partitions. This means that they need to put a bit more effort into using it, but they can use it in a more flexible way. For example, half is for the root filesystem and half is for the user home space. Probably 2 x 2.8GB is not the best match for having a toolchain on the smartphone compared to the 12GB available on the Xperia 10 mark 2.

After all, we need to take into account that there are 2 years between the release dates of the two smartphones, and the XA2 Ultra, at the time of its debut, was costing 37% of the price of the X10 II.

I used this on XA2 Ultra and it does work.
However I have to add that I don’t have encrypted home and that might complicate things.

1 Like

It did work on my XA2+ with unencrypted home

1 Like

It is a good way to rescue the unused space. Personally, I would go for the traditional way

mkfs.ext4 -m 0 /dev/mmcblk0p$n
mount -o gid=100000,uid=100000 /dev/mmcblk0p$n \


mkfs.ext4 -m 0 /dev/mmcblk0p$n
mount /dev/mmcblk0p$n /usr/share/extradata

This is a straightforward way to go compared to the LVM approach. However, the LVM approach grants much better integration but less control because we do not know which partitions are saved or where data is saved.

Moreover, the LVM approach includes a tiny but not null risk of compromising the data in the rootfs or user home space. That risk increases when the user who approaches the LVM subsystem has no background as a UNIX system administrator.

While the straightforward approach presented above can only fail to deliver the expected result as long as the user does not format the wrong partition, obviously. Coding bugs and human mistakes cannot be thrown out of the scene completely.

Finally, adding an extraspace on your user home by mounting and a formatted unused partition includes the risk of leaking some sensitive data that should have been encrypted by default but is in the extraspace folder.

In my opinion, people in Jolla should have rescued that space as the default operation when the first boot after flashing took place. I may accept that I have overlooked some criticality about using the unused partitions by default.

I would mainly try to use at least one of the partitions to enlarge my root.
Right now I have the newest update Struven Ketju ready for install but only 339mb free space…I cant find what else to delete just to free up 500mb for the update anymore.
It’s simply not feasible anymore to delete most SFOS apps everytime.

so the question would be:
Can I use one of the 2.8GB partitions and “enlarge” root with them?
How do I have to do this? With root I’m always very careful not to break something.

In this case you have to use the LVM approach or the mkfs+mount and use it to move all the /var data into the new partition. Before doing that check the size of the /var folder

du -ms /var/

in order to see if this part of your root filesystem has a size that allow you to gain enough space and can fit into 2.8GB partition leaving some reasonable space.

mkfs; mount in /tmp/var; cp -arf /var/* /tmp/var; umount /tmp/var;

now the risky part starting with edit /etc/fstab to add /dev/mmcblk0pX on /var

mv /var /var.old
mount /var
mount | grep "on /var "

in case the mount of the new /var succeed, then reboot. Cross the fingers, after the reboot check that everything is fine and then clean the old var with

rm -rf /var.old

Someone upgraded the system just updating the rpm repository and upgrading the 13 packages that has been modified. This will not require 500MB to be completed.

Moreover, check the cache folders in /var, you might find a lot of space to free.

find /var -name cache -type d | xargs du -ms 

I hope this helps, R-

Hi, i tried the description posted from the article posted by @davidrasch and it is AWESOME.

Really in a couple of steps during a meeting I was able to increase the root partition with 3GB.
Afterwards directly installed the newest update and rebooted…and so far no problems at all.

It was so simple that now I feel stupid not doing this earlier :slight_smile:


This post was flagged by the community and is temporarily hidden.

Man, what are you talking about, this has nothing to do with the issue.


This is the root cause because you had the issue in the first place.

The issue is not the issue, the issue is your perception of the issue.

I am trying to change your perception of the issue in such a way you would not have anymore issues but challenges to win. This is not about leadership, this is about education.

Obviously, you can always choose to stay ignorant and living in the belief that for the task X you need the app-X while, instead, universal tools and a pragmatic approach are the correct and general answer.

This post was flagged by the community and is temporarily hidden.

This post was flagged by the community and is temporarily hidden.