I made an error in my second post about clone the root partition. Noww corrected. See edit history.
In rsync, it is
/mnt/sfos/rootfs/
instead of
/mnt/sfos/
Some 1.5 years later, has someone succeeded in making full dd backup (and then restore) of rootfs and encrypted home of the 10 III and could share some details / experiences?
3 Likes
OK, so I’ve finally tested it with XA2 Ultra. The partition to backup in this device is mmcblk0p76 and the resulting .img file is slightly above 20 GB. It contains both rootfs and home. Restoring it took about 10 minutes.
Restore went flawlessly, except for that the Android support itself did not restore. The App Support page in Settings wasn’t showing any information - all fields were empty, API level was shown as 0 and App Support couldn’t be started. But it only took uninstalling and reinstalling App Support from the Jolla store to make it work again like it was prior to backup.
So the question is: where does Android App Support get installed? Is it some other partition than rootfs and home? Clearly so. In such case, it would take making a backup of that other partition, too, in order to be able to restore the OS in an identical state, including a fully working App Support…
========
Now, the next thing to test is the 10 III. I already made a backup of it. The userdata partition on the 10 III is sda79.
Unlike in case of the XA2 Ultra where it is 20 GB, on the 10 III it is 128 GB, which is quite troublesome. In order to fit it on a 128 GB memory card, I had to gzip the backup on the fly, i.e.
dd if=/dev/sda79 | gzip > /mnt/userdata.img.gz
which compressed the image from over 100 GB to 19 GB. It took more than 1 hour to do it.
But I’m yet to take the risk to try to restore it, as the 10 III is my daily driver and I currently cannot afford to possibly screw it and have to reinstall everything from scratch. But I guess that I won’t resist it for too long and I’ll try it soon.
BTW. Is there some other way than dd to backup a partition to an image file, but only the “used” part rather than the entire partition, bit by bit, including all the unused space? It is extremely time and space consuming on the 10 III to have to backup (and then restore) the entire 128 GB…
5 Likes
One easy optimization is to use cat instead of dd. This will likely be much faster.
or even better: just use gzip on the device directly. (like gzip -9 < /dev/sdb > /tmp/myimage.gz )
https://www.vidarholen.net/contents/blog/?p=479
(tldr: dd uses an absurdly small blocksize by default, this makes copying very very slow. Picking the optimal blocksize is automatically done by the kernel for almost everything else. Think of cp or cat as dd with optimal blocksize)
3 Likes
Good read, thank you! I’ll give it a try to check which one is faster. Cat may be much faster indeed, but also in this case I’ll still need to gzip the output on the fly (at least on the 10 III and its huge home partition) as I don’t have any spare / empty memory card large enough to hold uncompressed image. Which may turn out to be the bottleneck performance-wise. And upon restore it’ll still take writing all those > 100 GB to the partition, including some 80% of zeroes…
I’m wondering how Jolla makes it so that their userdata (sailfish.img001) image file is only ~1.8 GB and not the raw copy of the entire ~ 128 GB partition. Maybe they simply make such a small partition to only fit the files (and no free space) and this way get such a tiny image out of it.
P.S. Anyone knows where the Android App Support is installed so that it doesn’t get backed up / restored by imaging rootfs and home? Some other partition?
1 Like
Some internet sources say dd conv=sparse will produce a sparse image, i.e. one leaving out the empty parts.
Otherwise the tools dd_rescue and ddrescue (which are different things) can do it. But of course they are not readily available on SFOS.
4 Likes
There are faster compressors than gzip (Of course, the compression ratio is worse, but it might still be faster in the end), but I don’t know if they are available in your environment.
lzop and lz4 are the traditional fast compressor.
zstd covers a wide range from fast compression to high compression ratio (at low speed). Take a look into the documentation to find optimal parameters for your usecase.
Thank you, I’ll test dd with conv=sparse. I hope that it doesn’t take that the unused blocks are zero’ed first for it to work (i.e. recognize them as empty)…
1 Like
OK, so I created two backups (just to be secure) of the 10 III using both dd and cat. Sadly, NONE of them could be restored with fastboot, unlike on the XA2 Ultra. Fastboot gets stuck when writing one of the sparses (24th out of 30), and that’s it. Fortunately, I was able to restore the backup the same way I created it, i.e. in the recovery using dd if=/mnt/userdata.img of=/dev/sda79 but it is a surprisingly lengthy process taking 100 minutes, i.e. much longer than it took to create the backup… But it gives perfect result, the restored rootfs and home are identical, including correctly restored Android App Support.
3 Likes
Pretty sure the long write times are because of dd’s defaults for the bs parameter (as @thigg mentioned above).
Specifying something like bs=1M or so should speed up things.
I seem to remember one should use a size depending on some property of the underlying flash storage to save writes but can’t remember which.
5 Likes
Great idea, thank you! It reduced the time from 100 minutes to merely 39 minutes (write speed jumped from ~ 17 MB/s to ~45 MB/s). I got a perfectly restored system once again, including Android App Support. I only had to re-enter Jolla account credentials.
Prior to this last restore I reflashed my 10 III with Sony’s stock Android 13 (62.2.A.0.525), which gave me a much newer baseband. Everything works perfectly fine, and some things seem to actually work much better than on Android 11 (62.0.A.3.109) - that including the fingerprint sensor and display, which doesn’t seem to have the green/yellow tint issue even after I disabled the “BrightnessFix” service. Also, so far none of the people I called and asked about the echo issue confirmed hearing any echo…
So those things seem to be resulting from the Android OS present on the phone PRIOR TO reflashing to SFOS, and not from the Sony binaries flashed along with SFOS.
5 Likes
If you need compression to fit the 128GB partition to your SDCard, maybe using pigz instead of gzip could also speed up things a little.
Thanks for trying this out, i needed to do this, because i broke my 10iii. Did the backup of the old Xperias sda79 partition and wrote it back after installing SFOS on the new one. The phone needs to boot into SFOS afterinstallation before writing the filesystem back.
Everything seems to work, except that i had to reenter my wifi password.
1 Like
Fortunately, the partition turns out to be actually 104 GB so it fits nicely on a 128 GB card (which also isn’t full 128 GB but around 117 GB 
). Specifically for this task I bought some cheap Samsung Pro Plus 128 GB card with (allegedly) 180 MB/s read / 130 MB/s write speeds. As advised by @nephros, next time I’ll use bs=1M also for writing the backup to the card, so I’ll see how fast that card really is.
I just wish the recovery mode could be used like on the XA2 Ultra, i.e. without having to flash hybris-recovery.img to the boot partitions (and then reflashing to hybris-boot.img) each time one needs to use the recovery mode. On the XA2 it is enough to issue fastboot boot hybris-recovery.img to boot into recovery, without having to physically flash it (so I guess it goes to RAMdisk).
In my case WiFi password remained intact. Instead, I had to reenter Jolla account name and password 
1 Like
Sadly not everything works. I found 2 issues, i am not able to add fingerprints in settings, the okd ones still work.
I can only charge at a maximum of 450mah. If i shutdown the phone connect the charger, wait till the charge animation starts and then boot into the OS it is charging faster. But only until i remove the USB cable.
I’m going to do the whole process again and switch to Android 13 prior insralling SFOS.
1 Like
I do not have any problems with charging. I’ve just connected the XA2 Ultra charger and BatteryBuddy reports 1500 mAh charging.
Indeed, old fingerprints work but it’s not possible to add new ones. Maybe removing all fingerprints would make it possible to add new ones?
I’ll test if removing fingerprints works before i reflash. I will report back.
If fingerprints are blocked, you can reset them with, as devel-su:
systemctl stop sailfish-fpd
/usr/libexec/sailfish-fpd/fpslave --remove-all
/usr/libexec/sailfish-fpd/fpslave --flush-cache
systemctl start sailfish-fpd
2 Likes
@ric9k
Thank you!
The slow charging issue seems to be related to a bad usb port on the phone. The phone doesn’t connect to a computer, it is always in charging only mode. Fastboot does not work anymore. Boot mode also doesn’t work…
I’ve successfully used fastboot and developer mode connection. No problems of any kind. I’ve even downgraded to Android 11 (just to check some things) and then reflashed Android 13 again. So, indeed, it must have something to do with your phone’s USB port… Maybe cleaning it would help?
P.S. Does @ric9k’s suggestion fix the fingerprint problem? I can’t check it right now myself…
I’ll test this when i changed the USB board of the phone. If this does not work i’ll loose my remaining fingerprints…