Try
watch -n5 'kill -USR1 $(pgrep ^dd$)'
from another telnet session to get update about dd progress every 5 seconds.
Try
watch -n5 'kill -USR1 $(pgrep ^dd$)'
from another telnet session to get update about dd progress every 5 seconds.
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.
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.
What does it take to have ddrescue in SFOS recovery image, anyone here done the thought exercise?
cc Full dd backup of rootfs and /home as flashable images - #23 by nephros
I can’t recall details any more, but I once dd’dthe root partition from one Jolla to another, in attempt to fix it crashing. It worked fine for a few weeks, until it started hanging and crashing again.
I went into rescue mode and used dd to copy the root partition to a file in my computer and similarily put it into the bad device. Nothing extra needed really, if dd is a familiar tool that is
Sure, of course dd works, but this question is purely about getting better UX with ddrescue, which has many conveniences as defaults. We wouldn’t have to process tens of msgs about progress monitoring, for one
I did a new install of SailfishOS 4.6.0.13 on top of Android 13, and so far most things seem to work, and it has fixed the problem with echo on calls.
The only thing that doesn’t work now is scanning QR codes in Microsoft Authenticator Android app – if I try doing this, the camera freezes and then doesn’t work in any Android app (though it still works fine in native apps); if I don’t try scanning a QR code in Authenticator, camera works fine in other Android apps. Any ideas how to fix this?
Edit: scanning QR codes also doesn’t work in my banking app, and in the healthcare app; restarting Android AppSupport makes camera work again on other apps.
That happened to me as well when I flashed newer binaries…it got back to normal after I switched to the recommended binaries.
Fun, so I get to choose between no QR code scanning in Android apps and no echo cancellation on calls…
How do you know that this has anything to do with installing SFOS on top of Android 13? Have you tried it on Android 11 and it worked in such case?
No worries, if you flash the recommended binaries on top of Android 13 base, you’ll have no issues with the echo…or the camera, for that matter.
It worked fine before I reinstalled.
Which recommended binaries?
The ones recommended by Jolla (SW_binaries_for_Xperia_Android_11_4.19_v9a_lena.zip).
Hey @wetab73 , I just followed your guide and successfully backed up my system like this. Thank you!
Now, would you mind if I add your guide to sailfishos.wiki in order for it to be easier to find for other people?
Sure, please feel free to add it wherever it may help anyone.
I have a question regarding Android 13 here:
If VoLTE on Xperia 10 III doesn’t currently work with my provider, is there a chance for it to start working if I use a newer Android/Binaries?
Coincidentally, I completely reinstalled my daily driver (Sony Xperia 10 III) yesterday.
Encouraged by this thread I flashed Android 13 via Emma and flashed the latest Sailfish OS 4.6.0.13 alongside the recommended software binaries SW_binaries_for_Xperia_Android_11_4.19_v9a_lena
with the jolla flash script. I basically followed the installation instructions by jolla with the exception of the Android 13 base.
Color banding is gone. EDIT: I think some other users also reported this. The greenish banding is way less intrusive but on low backlight in a dark environment it is still noticeable. If I recall correct, the resulting colors of the Android 11 base in combination with the workaround of JacekJagosz were more natural. [X10II] [X10III] Color banding in low light conditions - #24 by JacekJagosz
No echoing issue reported. I have the impession that the device responds quicker and performs better overall, but this might be due to the “fresh install”.
But that didn’t affect my personal experiences with VoLTE. I have a pretty old sim card (> 10 years) from o2 germany. Calling via VoLTE works fine although I don’t get a ring back sound. Receiving SMS works fine but sending SMS is impossible*. SMS get transfered instantly if i switch VoLTE off though.
So you can expect improvements but I’m affraid not on the VoLTE side.
*Due to the fresh installation of SFOS 4.6.0.13 VoLTE was enabled by default and at my first test run I was able to send one sms. May be my phone wasn’t registered in a 4G cell already, but I wasn’t able to send another SMS afterwards.
Hard to tell. With binaries, you can simply flash various versions of them and see if it helps. Binaries can be reflashed anytime, without affecting SFOS installation in any way. Even if some version makes your phone non-bootable, you can just reflash it back to a working version. No harm will be done to SFOS.
As for the underlying Android, there’s more work to test various versions. A full image of rootfs and home partitions of SFOS (e.g. using dd) might help, as in such case you can always restore the OS to the imaged state.