Can't install Dec 2021 update

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 :thinking:
We clearly need more information, either my method is wrong, TWRP got installed to both slots or something else entirely.

:wave: Anyone with a unlocked bootloader (doesn’t have to be rooted) reading this

And post your hashes here :pray:

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 (:crossed_fingers:) 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 :slightly_smiling_face:

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… :thinking:

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

11 posts were merged into an existing topic: FP4: Google-free Android

Same hashes as @Aaanze, except that slot A and B are inverted :wink:
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: :slight_smile:

fastboot getvar all
(bootloader) current-slot:b

1 Like

Thank you :slightly_smiling_face:
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 :thinking:
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? :thinking:

According to your recovery hashes (thanks for confirming the hashes btw :metal:) 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 :crossed_fingers:

1 Like

I don’t know how I managed to change the xbl :sweat_smile:
In the worst case I’ll wait until FP releases the next full OTA Update or the complete system image.
Thank you so far!

Who knows when that will happen… :roll_eyes:

I’ll mess around with flashing a Fairphone back to vanilla in the next few days, I’ll let you know when (or if) I reach the point that’s safe to share :slightly_smiling_face:

2 Likes

I had OTA issues as well:
Build no. A.081
Rooted with Magisk
Unrooted
Several factory resets,
flashed images made available by hirnsushi and others.
Several factory resets,
„Strange behaviour“ of Slot B (did immediately switch to A on boot)
Download of OTA ok, but installation error.
So for weeks I was without update, rooted with Magisk.
Yesterday for any reason OTA installed…
now in February I have the December security patch. Juppiduh?!!
Build no. A.099.
Soon I am going to change to e/ or lineage.

Good luck/magic to all.

Build A.099 is still security patch level December, so you are on the latest update :+1:
They either forgot to change the string to January :roll_eyes: or actually didn’t include the newest patches :pensive: who knows… (I don’t, cause those are delta updates and a pain to extract)

I already updated to A.099, otherwise I would have helped you with that img.

I don’t know a lot about A/B slot, are all partition duplicated or only some of them? For example if I activate my inactive slot, could I recover the “old” xbl.img?

1 Like

Thanks anyway :slightly_smiling_face:

Here is a list of the A/B partitions:

FP4:/dev/block/by-name $ ls -m *_{a,b}
abl_a, abl_b, aop_a, aop_b, bluetooth_a, bluetooth_b, boot_a, boot_b, core_nhlos_a,
core_nhlos_b, devcfg_a, devcfg_b, dsp_a, dsp_b, dtbo_a, dtbo_b, featenabler_a,
featenabler_b, fsgbk_a, fsgbk_b, hyp_a, hyp_b, imagefv_a, imagefv_b, keymaster_a,
keymaster_b, mdtp_a, mdtp_b, mdtpsecapp_a, mdtpsecapp_b, modem_a, modem_b,
multiimgoem_a, multiimgoem_b, qupfw_a, qupfw_b, recovery_a, recovery_b, tz_a, tz_b,
uefisecapp_a, uefisecapp_b, vbmeta_a, vbmeta_b, vbmeta_system_a, vbmeta_system_b,
xbl_a, xbl_b, xbl_config_a, xbl_config_b

You can only extract the current and the previous build you had, updates essentially overwrite the slot you are currently not using. So in your case we could probably extract A.099 and A.094, but if the phone is new or wasn’t updated in between, those slots can contain almost any combination of previously released builds.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.