Android 13 and SailfishOS on Xperia 10 III

[olf]

@thigg

Flashing android and reinstalling sfos took about 1h for me as well (most of the trouble was reviving a windows pc).

You introduced the necessity to reinstall SailfishOS only to restore the LVM volume layout by backing up on LVM volume level. IMO this is pretty senseless, either backup on block device level (/dev/sda79 for the Xperia 10 III) or on filesystem level for regular backups using tar (but the latter is unsuitable for the purpose here, i.e. backing up the complete SailfishOS installation).

If one wants to backup to another device (instead of on SD-card), the easiest way is to pipe into or from scp (in order not to resort to ancient tools as rcp or netcat).
I.e. for backing up
dd if=/dev/sda79 bs=4M | scp <user>@<host>:<directory>/backup-sda79_$(date -I).img
and for restoring
scp <user>@<host>:<directory>/backup-sda79_$(date -I).img | dd of=/dev/sda79 bs=4M

P.S. / Edit: Oops, scp does not seem to be able to read from or write to a pipe.

So one may try this (also untested):

• Backup on your PC by
  ssh root@10.42.66.66 "/usr/bin/cat /dev/sda79" > backup-sda79_$(date -I).img
• and restore from your PC by
  ssh root@10.42.66.66 -T "/usr/bin/cat > /dev/sda79" < backup-sda79_<hit-tab-to-autocomplete>.img

P.P.S.: @niquest did it by using netcat (nc).

[thigg]

You dont need to reinstall sfos before recovering from the backup?
i should have read that more carefully.
i was only playing around with home and root because i wanted to see what effect encryption has. Your approach is probably better

[lkraav]

You dont need to reinstall sfos befote recovering from the backup?

Correct, that’s what makes it worth trying on a daily driver. Reinstall is a real chore.

[wetab73]

@olf

As @thigg correctly pointed out, only the LVM meta-data and the content of the root volume are compressible, the whole home volume is not due to its encryption. Hence one might as well perform the backup as @wetab73 suggested, because there are only a few Gigabytes to be saved by compression, at most.

That’s the reason why I only mentioned uncompressed backup in my post. Compression (well, at least gzip that I’ve tried) is quite slower and doesn’t seem to be helping much.

@thigg

got still color banding when using nightish and lowest settings in a dark room. That should have been fixed, right?

I don’t remember having seen any banding since I started using Android 12 (along with Android 12 binaries), but I haven’t tested it with nightish. I’ll give it a try.

@lkraav

I flashed A11 binaries back: Android camera functionality was immediately restored.

Well, I’ve only ever used A12 binaries together with Android 12 OS as base for SFOS (and that was actually the reason of using them - to have a matching pair), so I can’t tell how they behave on top of Android 11.

Anyway, as I wrote earlier, I actually haven’t noticed any improvements that would result from changing the binaries because all fixes (including the echo issue, banding/color tint and fingerprint sensor functionality) apparently come from upgrading the underlying Android OS to version 12 or 13, and not the binaries. So I guess it is OK to just stick with Jolla recommended A11 binaries, or in case of using Android 12 as base OS for SFOS one may also use A12 (v2a) binaries to have a matching pair that may POSSIBLY give some advantages (or not ) but in that specific combination (Android 12 62.1.A.0.675 as underlying OS, Android 12 v2a binaries) after weeks of tests don’t seem to be causing any issues.

@thigg

You dont need to reinstall sfos before recovering from the backup?

You do need to reinstall SFOS prior to restoring the backup in the case that you wiped the existing SFOS installation (e.g. by reflashing Android using EMMA). Or in such case you need to at least manually flash the remaining partitions that SFOS uses, which are not in your /dev/sda79 backup (that only contains rootfs and home). Namely:

fastboot flash boot_a hybris-boot.img
fastboot flash boot_b hybris-boot.img
fastboot flash dtbo_a dtbo.img
fastboot flash dtbo_b dtbo.img
fastboot flash oem_a Sony_binaries.img

[thigg]

We should compile that info into a wiki post

[wetab73]

Good idea. One more thing worth including in such a wiki post is that after restoring the /dev/sda79 backup it is sometimes not possible to add new fingerprints without doing the following. The existing fingerprints work OK, but if one wants to add new ones it takes wiping them and the cache first, as suggested by @ric9k here:

systemctl stop sailfish-fpd
/usr/libexec/sailfish-fpd/fpslave --remove-all
/usr/libexec/sailfish-fpd/fpslave --flush-cache
systemctl start sailfish-fpd

and then it works as usual. I’ve tested it multiple times after each restore and it always works, so there’s nothing to be worried about, just an additional easy step to do after restore.

This is regardless of underlying Android OS version, binaries version, etc.

[ric9k]

@wetab73

suggested by @ric9k

(which took it from @spiiroin here )

[lkraav]

@lkraav

I flashed A11 binaries back: Android camera functionality was immediately restored.

Uh, and this binaries experiment gets even weirder: color banding, or “paint blobs” is also gone now. Damn, turns out I should’ve taken photos of the device screen to document I’m not crazy

I’m looking at the exact same “Work” app launcher folder I screenshotted earlier at Android 13 and SailfishOS on xperia 10 III - #61 by lkraav and there’s zero weird color banding on screen, everything now looks exactly like in the screenshot - translucency, shadows are all perfect.

[wetab73]

@lkraav

I’m looking at the exact same “Work” app launcher folder I screenshotted earlier […] and there’s zero weird color banding on screen

Maybe lighting conditions were different. This color banding issue only becomes apparent with very low screen brightness, so with an automatic display brightness it takes being in a dark place to see it.

[lkraav]

@wetab73

Maybe lighting conditions were different. This color banding issue only becomes apparent with very low screen brightness, so with an automatic display brightness it takes being in a dark place to see it.

Yes, confirmed! In a pitch black dark room, color banding is visible. OK I think now that’s all there is to know about it, thanks. Will test full A12 juggle next week.

[Valorsoguerriero97]

oh yeah, I don’t have the Sony anymore, but remember that colors… man, how bad they were. With A12 or A13 that’s solved

[niquest]

Hello, picking up this thread on the “backup wiki” subject. I am not very fluent with linux bash but is it even possible to use dd on a “live” device? Will I not get corrupted data? Or am I missing something?

[niquest]

I think I answered it myself. It is not live. Sorry for the uninformed question.

[root@Xperia10III dev]# umount /dev/sda79
umount: /dev/sda79: not mounted.

[thigg]

Sda79 actually contains 2 partitions: root and home. Thus sda79 is not mounted but its contents are. On a live system those change during dd and corrupt the backup. The backup should be done via the recovery.

[niquest]

Thanks for the insight. Can you confirm it works like this:

• flash the hybris-recovery image respectively to boot_a and _b using fastboot
• reboot
• telnet to the device
• file a public key on the device
  → then proceed with dd activity via ssh?

By the way, the above command didn’t work out for me but I was able to make it work like this (ssh’d into device and as devel-su):

dd if=/dev/sda79 bs=4M | ssh myusername@
address 'cat > /mypath/dd/backup-sda79_$(date
 -I).img'

As a side note, I found out that when running dd on Sailfish it seems impossible to monitor the data transfer by either calling ‘status=progress’

dd: invalid argument 'progress' to 'status'

or to view the pipe content by inserting a ‘| pv |’ as in was suggested on some forum:

dd if=/dev/sda79 bs=4M | pv | ssh potato@address

result:

bash: pv: not found

Anyway thank you very much for your help!

[wetab73]

Try

watch -n5 'kill -USR1 $(pgrep ^dd$)'

from another telnet session to get update about dd progress every 5 seconds.

[thigg]

There are a couple of approaches in this thread. One is this which matches what you say

[niquest]

Thanks for pointing it out.
Your linked post by @wetab73 only partially matches my query as I want to dd my /dev/sda79 to a network drive as suggested by @olf and not to an sd card (it’s a size issue). I am currently using telnet and investigating netcat which appears to possibly run in recovery mode.
I only have a limited idea of what I’m doing but I find a discrepancy between the way recovery mode seems to work and the idea of dd’ing large data via scp. OTOH, ssh and with it scp seems to preclude copying an unmounted volume because it would run on the same?

If you guys think that this discussion is misplaced here please say so and I will remove it and attach it to an appropriate thread (haven’t found one so far) or open a new one.

[thigg]

Maybe this helps you? Android 13 and SailfishOS on xperia 10 III - #78 by thigg

[niquest]

Thank you for reminding me of this. It is helping me a lot now that I understand a little bit more about what I am trying to do.

Meanwhile I managed to send the dd stream via netcat to a local volume. For anyone interested:
Target side:
nc -l 19000 | dd bs=4M of=/pathto/volume/Sailfish.img

Source side:
dd bs=4M if=/dev/sda79 | nc 10.42.66.xx 19000

Monitored progress with suggested Android 13 and SailfishOS on xperia 10 III - #95 by wetab73 (thank you). It took ages but it looked to be a success.

Will try the publickey move you suggested for further investigations.