TWRP for Fairphone 3

I can’t check for myself right now, but you could have a look at the Addendum at the end of this post and see whether TWRP reports the file system for the SD card that way.
(Just don’t proceed with the formatting there :wink: .)

1 Like

Hi there,

i flashed A.110, then i installed twrp.zip and magisk.zip. After erasing userdata with fastboot -w everything works fine so far… but if i relock the bootloader i always get an error message

Your device is corrupt. It can’t be
trusted and will not boot

This is caused by the modified boot.img:

2 Likes

Direct hit! And thanks to @AnotherElk for the TWRP trick. My file system is vfat. I’ll format my microSD card and try again. :slight_smile:

Edit: And “Backup completed in 836 seconds”. :tada:

Edit2: Bummer, exFAT is not recognized in /e/… :roll_eyes:

1 Like

Is TWRP backup for FP3 different from TWRP backup for FP2 (as TWRP for FP2 split backup files into pieces of max 1.5GB)? :thinking:

1 Like

Does /e/ say that … or does it “only” want to format the card it sees for the first time?
If the latter … /e/ wanted to format my card, too, and my card was not exFAT formatted. I think the Fairphone 3 stock OS wanted to do that, too, but I don’t know if I remember that correctly, I didn’t take notes then.

Explicitly missing exFAT support would surprise me, as I found LineageOS on the Fairphone 2 would support exFAT.

But it’s of little use if Android insisted on formatting and wouldn’t let you choose the file system.

Be aware: I ran into createTarFork() ERROR 255 on restore as well. On both, a backup on internal storage (ext4) and as well as on a backup directly stored over usb to my harddrive via adb backup --twrp. There is an unresolved bug in TWRP that can more or less randomly lead to corrupted backups without the exact cause being known. Do not rely on TWRP as your sole backup solution!

If you want to restore the data partition on a Fairphone 3 with TWRP, before restoring make sure that encryption would be set up the same way as when the backup was made.

I have successfully restored the complete state of the phone following these steps …

  • Install the OS build that matches the data partition to restore.
    (I needed to match the build this way, else restoring the data partition would fail.)
  • Boot the installed OS, set up the screen lock (= the decryption method) in the same way it was set up when the backup of the data partition was made.
    (Else restoring the data partition would fail.)
  • Restore the data partition with TWRP.
  • Copy the whole Internal Storage back to the phone (since TWRP doesn’t include Internal Storage in a backup, so I always use other means to backup Internal Storage).
1 Like

Interesting, I assume this an issue with the way TWRP performs the restore? Because in theory, the backup data should contain everything that’s required to restore the previous encryption state, no?

I also observed that the TWRP factory reset did not work properly (system would still not boot after wiping). The only way to get the phone into a bootable state for me was to use the factory reset feature of the default recovery partition.

1 Like

There are some topics discussing missing support for file systems over at the /e/ community:

1 Like

I have a rooted FP3, but the system was in RO. Is there any particular reason that I can not do the new update?

1 Like

Can anyone please provide an image of 0118 or 0120? Even though I rooted with system as read only, I can’t do the OTA update, I lost my backups of my 0118 partitions, and I’m not so keen on reverting back to 0110 to update twice.

1 Like

Here you are:

I guess @CosmoSteve meant either a TWRP-installable stock package or a fastboot-flashable stock partition dump.

I think until now nobody was able to manually install an OTA update file successfully …

1 Like

It should be possible to install the OTA manually via TWRP.
However that will have the same restrictions as updating via the OS.
I.e. no modifications to the installed system.

1 Like

If anyone writes me a (comprehensive) to-do list, I’ll revert back to A0111, do the updates up to A0120 and then dump the stock partitions. I couldn’t figure out how to extract stock partitions yet, so I need someone to explain it to me.

1 Like

Another option is to apply the updates on a PC using This fork of payload_dumper by @corvuscorax and create full images that way.
I’m sorry, I haven’t had the time to provide newer full images, I’ll look into it.

2 Likes

I have dumped the full a/b partitions of an unmodified A.0120 via firehose, luckily with the A/B scheme A.0118 was also available as the old inactive slot:
https://data.lrnz.org/fp3/stock/

Is there an easy way to extract the sha256 values (and sizes) for all partitions from the OTA packages? (to allow verification of the images)

Note that these are full images of the partitions and might need to be truncated for the sha256sum to match, i.e.

$ head -c 1650688 aboot.bin | openssl dgst -binary -sha256 | openssl base64
2qMGLGDBFCqka93pztTtXcrzYzs+QY+Onlu5e9fz/0M=

matches what I found in my logcat from the A.0120 update:

PartitionInfo new aboot sha256: 2qMGLGDBFCqka93pztTtXcrzYzs+QY+Onlu5e9fz/0M= size: 1650688
1 Like

Replying myself after reading a bit into the source:

The payload_dumper mentioned above can do that verification by updating the A.0118 images with the A.0120 ota and comparing the result with the A.0120 images (after truncating them to the same size).

Example output for aboot:

Processing aboot partition... Checking original Sha256, should be b'yhcG8fijO/ly6BBArVhgQ2/SCmZcRMjl/WtQpv0ZV+A=' ... passed... 
extracting... truncating... Checking new Sha256, should be b'2qMGLGDBFCqka93pztTtXcrzYzs+QY+Onlu5e9fz/0M=' ... passed... done

Excuse my noobish question, but can we flash those .bin files as if they were .img files?