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)
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?
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.
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)…
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.
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.
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.
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.
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 
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.
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@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…
Maybe try to clean the USB port first. It’s possible that one of the data pins is dirty, and that’s why it only works in charging mode. My wife had a similar problem with the Lightning port (or whatever they call it) on her iPhone and using a drop of isopropyl alcohol made it work again like new.
That worked, thank you!
That’s great! So it means that there are actually no other known side effects of flashing SFOS on top of Android 13, whereas the lack of echo and color banding / yellow tint issues is a huge benefit of doing so.