View Single Post
Posts: 88 | Thanked: 411 times | Joined on Mar 2010 @ southern Italy
#2143
Some extra notes about reclaiming a few gigabytes disk space to add to root and/or home logical volumes:

Originally Posted by alfmar View Post
reclaim about 6.6 Gb
Facts:
- only partitions 51 and 52 need to be touched for reclaiming some gigabytes for root and home logical volumes;
- partition 51 (user partition) is managed by lvm (as a volume of 5298 blocks of 4Mb each, as of the devel-su vgdisplay command) as a volume labeled "sailfish" containing two ext4 partitions (/dev/sailfish/root and /dev/sailfish/home) that lvm can resize when not mounted (that is: early boot time)
- partition 52 (factory reset image partition) is formatted as ext4 (even if not marked as such in the partition table) and contains ~600 Mb of data (actually only two compressed image files and md5sum files)
- fdisk doesn't save changes until you explicitly command it.

My assumptions:
- future upgrades won't need to alter partition 52 contents (just verified the 2.1.3.7 doesn't touch the partition 52, see below);
- thus that factory reset image only needs less than ~700 Mb, it shouldn't ever grow;
- then we can delete/create/fill partition 52 at some higher startsector address (the last ~700 Mb of mmc storage) and make it again an ext4 containing the same factory reset image files
- fdisk can delete/create partitions without altering disk contents (when you "delete partition 51", as long as you create again a partition 51 starting from the same startsector and at least as big as the former partition 51 before rebooting, you don't lose its data)
- logical volume manager can resize its logical volumes without losing data (i.e., no need for a "partition resizer").

Risks:
- until the unlikely event of getting a serial port console or a method to boot off microSD, messing with the boot sequence (kernel, boot partitions, etc) may brick the phone, because everything -including the factory reset option- depends on a bootable kernel accessing the right partitions containing the right data. If anything goes wrong while messing with fdisk and partition 51 and volume manager, the Xperia is probably bricked.

I tried this before upgrading to 2.1.3.7:
Code:
[nemo@Sailfish ~]$ devel-su
Password: 
[root@Sailfish nemo]# mount /dev/mmcblk0p52 /mnt
[root@Sailfish nemo]# cd /mnt
[root@Sailfish mnt]# cd SailfishOS-2.1.3.5-f5121-0.0.1.16/
[root@Sailfish SailfishOS-2.1.3.5-f5121-0.0.1.16]# ls -al
total 604520
drwxr-xr-x 2 root  root       4096 2017-10-11 08:59 .
drwxr-xr-x 4 root  root       4096 2017-10-11 08:59 ..
-rw-r--r-- 1 99001 77777 125079724 2017-10-11 08:46 home.img.gz
-rw-r--r-- 1 99001 77777        46 2017-10-11 08:51 home.img.gz.md5
-rw-r--r-- 1 99001 77777 493920074 2017-10-11 08:46 root.img.gz
-rw-r--r-- 1 99001 77777        46 2017-10-11 08:50 root.img.gz.md5
[root@Sailfish SailfishOS-2.1.3.5-f5121-0.0.1.16]# cd; umount /mnt
Soon after upgrading to 2.1.3.7 I verified it again, and the four *img.gz* files are still there untouched - same size, same date.
__________________
 

The Following 3 Users Say Thank You to alfmar For This Useful Post: