Strange, well, let’s do it manually then:
$ adb shell
FP4:/ $ logcat > /sdcard/logcat.txt
… and then rest of the steps.
Just amended the title, to add date, as there may well be others. Probably better to add real update title.
Good point, I’ll keep that in mind
1 Like
The log is cut off before it get’s interesting 
01-12 15:25:50.116 6527 6527 E ActivityThread: at android.content.ContextWrapper.bindService(ContextWrapper.java:756)
01-12
Could you check if your logcat.txt is as well? 
Damn, I should’ve double checked that. Just searched for a fileshare site, I doubt a codeshare site will allow me to upload everything
You can also just attach the file to your post next time.
So, let’s see, first of all, we now have the link to the ota.zip, that might come in handy 
And this error here looks promising:
01-12 16:02:00.988 1384 1384 E update_engine: [ERROR:delta_performer.cc(431)] Unable to open ECC source partition recovery on slot A, file /dev/block/bootdevice/by-name/recovery_a: Success (0)
01-12 16:02:00.989 1384 1384 E update_engine: [ERROR:delta_performer.cc(1155)] The hash of the source data on disk for this operation doesn't match the expected value. This could mean that the delta update payload was targeted for another version, or that the source partition was modified after it was installed, for example, by mounting a filesystem.
01-12 16:02:00.990 1384 1384 E update_engine: [ERROR:delta_performer.cc(1160)] Expected: sha256|hex = AC800864700E98E449C53A6F9B1BA0097440FFAEB2F2FFE93007442B110BE335
01-12 16:02:00.991 1384 1384 E update_engine: [ERROR:delta_performer.cc(1163)] Calculated: sha256|hex = 0D15E2429A87C860B3EA29C75D386AB0103A1BEADF106CE6CDC92F01E8187E4C
Did you by any chance flash TWRP to your device? 
1 Like
Yeah, I did. And how would I attach the file? .txt is not allowed
I’ll check if I can get you a recovery.img with a matching hash from one of the devices I have access to 
For the record TWRP shouldn’t be installed on newer Android devices if you don’t absolutely have to. Just run it with $ fastboot boot twrp.img
Ah, sorry, didn’t know that 
Yeah, I should’ve informed myself better about that. It’s been a while since I bought a new phone and I just assumed it still was a thing. A stock recovery.img would be great, though
As suspected I don’t have the right recovery.img, I got those two hashes:
3755d4a779ba98de79186e95981609b732061ffa8f3505de4c280a0d440558af(A.091)ca296287940c69fd28efad125a71bb2212afc0dd8d2af63ea55a1d4d3daa0db7(A.094)
You are on A.081, I assume. At least I found the second hash on both phones, so nothing device specific going on.
I’m also not a hundred percent sure my method to get those hashes is actually the right one, all I could find in the docs was:
Small partitions, such as
bootanddtbo, that are read only once are typically verified by loading the entire contents into memory and then calculating its hash. This calculated hash value is then compared to the expected hash value. If the value doesn’t match, Android won’t load.
Could you please boot your phone from a rooted boot.img and then run
$ adb shell 'su -c "sha256sum /dev/block/by-name/recovery_{a,b}"'
If there’s 0D15E2429A87C860B3EA29C75D386AB0103A1BEADF106CE6CDC92F01E8187E4C in there we are actually on the right path
Happens, I dded all my partitions from one slot to the other when trying to get the other slot bootable 
My next update will be just as fun as yours 
This is all new to me too, Android 11 on the FP4 is like a completely different OS compared to Android 11 on my Nexus 4, things have changed a lot…
That’s weird cause I’m definitely on A.091 (build number FP4.FP3N.A.091.20211118)
I just booted from the rooted boot.img but the command returns “inaccessible or not found”.
Ah, right, so the other slot is on A.081 probably. I’m on A.094 and my other slot is A.091.
Did you copy and paste the commands I posted? I noticed you had the wrong characters in your command before
' and ’ are hard to distinguish sometimes.
Otherwise we just take the manual route again, maybe it’s something Windows specific I don’t understand:
$ adb shell
$ su
# sha256sum /dev/block/by-name/recovery_{a,b}
There will be a dialog on your phone to grant the su request.
It seems to be something windows specific, the manual route worked again: 9358dc6e623d213992e1c1c14b340f07524641491453f3c7065b723e4024df46
/dev/block/by-name/recovery_a
425382d5857f04fc49585cabbdef6fc647472ee26f52c54caaaeaad17320b3f8
/dev/block/by-name/recovery_b
How would I go about flashing both slots? The only way I’ve seen so far is with TWRP but I don’t think it’s working properly
Damn, those are not the hashes I was hoping for, at least one should match with mine
We clearly need more information, either my method is wrong, TWRP got installed to both slots or something else entirely.
Anyone with a unlocked bootloader (doesn’t have to be rooted) reading this
And post your hashes here
You can flash a .img to a specific slot by using something like fastboot flash recovery_a /path/to/image.
I wouldn’t suggest trying to flash one slot over the other without more information. Let’s wait for someone to post their hashes () and take it from there. Without a dump of the right recovery.img there’s not a lot we can do. Maybe hope for FP to release a stock recovery.img in the meantime 
No worries, I haven’t been using the phone anyway since I’m waiting for the e/os release. But I guess the stock recovery is something to ask FP about directly? Maybe they’ll consider releasing it if people ask for it?
1 Like
Probably not helpful as my hashes are yet different than yours but, here they are…
ca296287940c69fd28efad125a71bb2212afc0dd8d2af63ea55a1d4d3daa0db7 /dev/block/by-name/recovery_a
55fcec22e71a0623a1d92fcff69def3d9542fbd2677a7c38d2b59f1974d84253 /dev/block/by-name/recovery_b
1 Like
Those are great, your first one matches the one I found on two devices already, that should be the A.094 recovery. Not sure about the second one though, interesting…
Let’s see if we can get this figured out before everyone interested jumps to /e/ and that window closes forever.
What do you mean ? (slow mind here)
Well it seems the /e/ images will be available later today
We need someone with a phone not updated to A.094 to dump their A/B partitions, that should, in theory, include the A.081 partitions the phone shipped with and we need to fix this problem.
The /e/ images are almost certainly full upgrades, so anyone flashing those won’t be able to dump us those partitions, everything interesting will be overwritten.
The pool of people who are still not upgraded, are in this forum and are willing to dump those partitions is probably very small already, once /e/ releases, that number approaches zero.
1 Like