DrYak | # 2141 | 2017-11-12, 21:34 | Report

That, or: ...depending on the severity of the problem.

lantern | # 2142 | 2017-11-13, 12:48 | Report

2.1.3.7 update overwrites /etc/ofono/ril_subscription.conf on F5122.
So you need to edit it again to have the phone functions working.

---

Last edited by lantern; 2017-11-13 at 12:55.

alfmar | # 2143 | 2017-11-13, 16:06 | Report

Some extra notes about reclaiming a few gigabytes disk space to add to root and/or home logical volumes:

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:
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.

lantern | # 2144 | 2017-11-13, 16:20 | Report

alfmar
I posted a manual to resize parts 51 and 52 somewhere here. Upgraded to 2.1.3.7 today - all good.

MartinK | # 2145 | 2017-11-13, 16:38 | Report

I think the recovery image files might still be updated in the future, so that people don't have to install a bazillion of updates if they ever do a factory reset.

This is a huge benefit of this recovery implementation (easy to update files on a separate partitions) compared to the old one (basically unupdatable/hard to update BTRFS snapshots).

Still even if they for example kept the last two recovery file versions around it's unlikely it would every use the full 7 GB available.

lantern | # 2146 | 2017-11-13, 16:41 | Report

they won't use 7GB ever, as /fimage partition is formatted only to 1.4GB on sailfishx

Heik | # 2147 | 2017-11-13, 17:51 | Report

I had to modify again /default.prop , but /etc/ofono/ril_subscription.conf was not overwritten as far as I remember.
http://talk.maemo.org/showpost.php?p...postcount=2092

DrYak | # 2148 | 2017-11-13, 17:52 | Report

Correct me if I'm wrong, but Jolla's recovery kernel only relies on its embed initrd ramdisk (that was certainly the case on Jolla 1)

It doesn't rely on data nor recovery partitions. You could nuke them and the recovery will still boot.
(But you won't be able to use the "factory reset" entry from the telnet menu. You'll have to drop into a shell a fix by hand).

So you could OFF ; Volume-key Down ; USB cable :
then OFF ; Volume-key Up ; USB cable for recovery ; follow on-screen instruction to telnet.

Or more directly :
to straight load and boot it without even writing it to flash.

I haven't had time to investigate yet, but I strongly suspect that the bootloader itself isn't stored on the eMMC flash.
So fastboot mode should work even without it, and fastboot boot should be entirely be doable in-RAM.
Thus this last option should still work even if you completely **** up the whole GPT partition and need to re-partition manually.
(But this isn't a guarantee. Maybe the bootloader needs to do something silly, like checking a checksum or a signature in order to decide if it needs to display a warning, and crashes in case of corrupt partitions)

hhbbap | # 2149 | 2017-11-13, 20:26 | Report

Perhaps you might need to active the SIM card first on web?
Telenor in Norway has that as routine to protect SIM cards sent by post.
Regards, Frode

Breeze5 | # 2150 | 2017-11-13, 21:37 | Report

No, that's not the problem. We do/have like this: when you get your new SIM and plug it in, it connects to the network and the old one is dissabled at the same time, takes about 15-60 min. My new SIM works fine in my N9 and N900. I have a carrier locked phone =/

EDIT:
But this i wonder:
You can unlock the carrier by going into service menu and enter a code you can buy online.
But how do i access the service menu with SFOSX? Android is the *#*#7378432#*#*