my SANDISK sd card, which worked flawlessly before the update, is deemed to need to be formatted. Checking this SD card on my desktop PC has shown a slight problem, but after the repair by Windows it is working fine again. I can read from it and write on it. Are there any new restrictions on this new version that impede my sdCard from being accepted as it is?
I tried to undo the OTA by changing to the other slot (the old one, “b”, with /e/ 1.4 on it) under Fastboot. After booting from that other slot “b” I ended up in recovery and could not boot into the old /e/. So, this did not work and I changed back to the new slot “a”. Is it possible at all to revert to the old OS on the inactive slot?
I’m on IMG-e-1.5-r-20221030230467-dev-FP3 and see the trustzoneaccess fatal too:
dlopen failed: library "libnative-api.so" not found
logcat
E AndroidRuntime: FATAL EXCEPTION: main
E AndroidRuntime: Process: com.qualcomm.qti.qms.service.trustzoneaccess, PID: 5126
E AndroidRuntime: java.lang.UnsatisfiedLinkError: dlopen failed: library “libnative-api.so” not found
E AndroidRuntime: at java.lang.Runtime.loadLibrary0(Runtime.java:1087)
E AndroidRuntime: at java.lang.Runtime.loadLibrary0(Runtime.java:1008)
E AndroidRuntime: at java.lang.System.loadLibrary(System.java:1664)
E AndroidRuntime: at com.qualcomm.qti.qms.service.trustzoneaccess.TZAccessService.(TZAccessService.java:15)
E AndroidRuntime: at java.lang.Class.newInstance(Native Method)
E AndroidRuntime: at android.app.AppComponentFactory.instantiateService(AppComponentFactory.java:129)
E AndroidRuntime: at android.app.ActivityThread.handleCreateService(ActivityThread.java:4177)
E AndroidRuntime: at android.app.ActivityThread.access$1500(ActivityThread.java:237)
E AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1932)
E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:106)
E AndroidRuntime: at android.os.Looper.loop(Looper.java:223)
E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:7664)
E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)
The sdcard wasn’t detected as needing a format. Access works.
Don’t think it both issues 1+2 are connected
For 3: A change of boot slot should work in theory, but unsure about userdata preservation: I had to reset for it to successfully boot at times, at the complete loss of userdata.
After update (1.5-20221028230215), everything works well on my FP3+ except for the following issue with my SD card (formatted as portable storage):
The card works fine and is recognised while on battery (I can mount and unmount it and no issues)
The card is flagged as “corrupted” if I connect my device to the USB-C charger and urges me to reformat it, however once I reboot the phone and it is on battery again, it is fine once more.
This problem only occurred after this update (1.5-20221028230215), no issues before this.
As long as the security patch level is the same, you can revert by switching the slot (if you kept the bootloader unlocked to allow this switching), keeping your user data.
If the security patch level on the updated slot is more recent than on the slot you are switching to, the boot process after the switch will be interrupted for the Try again / Factory reset prompt. If you choose the factory reset, wiping user data, the older OS version should indeed boot successfully.
@AnotherElk ah thanks. True! after being marked as having booted successfully, the other slot is of no use. But if the device is unlocked and someone wants to do testing/development, one should be able to edit/reset the vbmeta entries that forbid the rollback.
That would have helped big-time. The thing is, I had to restore a TẂRP backup in order to get my old system back.
Now I am on 1.4q again, and the 400GB micro sd card works fine again - flawlessly. There seems to be new restrictions in Android 11 (and /e/1.5r) regarding storage space. And evidently a substantial bug in /e/os1.5r.
By the way, it took me lots of work and hours to restore the backup I’d made with TWRP. I ended up time and again with the dreaded “255” [extractTarFork( ) process ended with ERROR: 255] error. It took me tons of trials and errors until I eventually had success. What did the trick was: I wiped everything in TWRP, formatted the data partition, followed the official /e/ install instructions to the letter except closing the bootloader, booted the phone with Fastboot to TWRP and had TWRP flash the “data” partition of /e/1.4q only. I am writing this as there is evidently a lot of confusion about what to backup and what to restore with TWRP on which occasions.