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
Same hashes as @Aaanze, except that slot A and B are inverted 
I’m on A.094 and (if I remember well) I was previously on A.091. Not rooted.
FP4:/ # sha256sum /dev/block/by-name/recovery_{a,b}
55fcec22e71a0623a1d92fcff69def3d9542fbd2677a7c38d2b59f1974d84253 /dev/block/by-name/recovery_a
ca296287940c69fd28efad125a71bb2212afc0dd8d2af63ea55a1d4d3daa0db7 /dev/block/by-name/recovery_b
And I can also add that A.094 is the one on my slot B: 
fastboot getvar all
(bootloader) current-slot:b
1 Like
Thank you 
The same hash for A.094 on four phones is good news. Not sure why I’m an outlier with my second hash, that phone was only unpacked and updated from A.091 to A.094
That still won’t tell us if running sha256sum on the partitions actually has anything to do with the way the SystemUpdater checks the hash, but the next security update should provide that information.
OP has switched to /e/ anyway, so the new goal is probably to better understand verified boot and if possible, find someone with a A.081 recovery.img. That would be great to help people that flashed TWRP by accident but want to stay on vanilla FPOS.
2 Likes
Hello everyone,
after rooting I can’t install the newest OTA (A.099).
Already tried all the recommended, but looking at the logs I found:
The log shows that the Updater doesn’t accept the hash of xbl:
02-05 03:21:43.715 1349 1349 I update_engine: [INFO:delta_performer.cc(397)] Applying 22 operations to partition “xbl”
02-05 03:21:43.718 1349 1349 I update_engine: [INFO:delta_performer.cc(657)] Starting to apply update payload operations
02-05 03:21:43.741 1349 1349 E update_engine: [ERROR:fec_file_descriptor.cc(30)] No ECC data in the passed file
02-05 03:21:43.743 1349 1349 E update_engine: [ERROR:delta_performer.cc(431)] Unable to open ECC source partition xbl on slot A, file /dev/block/bootdevice/by-name/xbl_a: Invalid argument (22)
02-05 03:21:43.744 1349 1349 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.
02-05 03:21:43.745 1349 1349 E update_engine: [ERROR:delta_performer.cc(1160)] Expected: sha256|hex = 37B5C32F06A11190F7BC838F4AFA3F26C5B79DB31C4CD978F2D7C4E3A8F5FF52
02-05 03:21:43.746 1349 1349 E update_engine: [ERROR:delta_performer.cc(1163)] Calculated: sha256|hex = C4663DA0CD63A5BEAD6AD1F498D420126C093FDEAE81E5F6A4AF53976C6766AB
Does someone have the original xbl from A.091 (not sure if this is the version needed)? Or do we know when the next full OTA is scheduled?
If it is still relevant to the previous discussing, here are my recovery hashes:
55fcec22e71a0623a1d92fcff69def3d9542fbd2677a7c38d2b59f1974d84253 /dev/block/by-name/recovery_a
ca296287940c69fd28efad125a71bb2212afc0dd8d2af63ea55a1d4d3daa0db7 /dev/block/by-name/recovery_b
EDIT: Changed needed xbl version.
Huh, interesting, how did your xbl partititon get modified?
According to your recovery hashes (thanks for confirming the hashes btw 
) you are on A.094 in slot B, slot A should be A.091. So you are actually looking for a xbl.img for A.091 I think.
Sadly that’s one of the update generations I’m missing right now. None of my hashes are matching yours.
Let’s hope someone not updated to A.099 can check their hashes and dump that xbl.img for you
1 Like