TWRP for Fairphone 3

[Volker]

@k4y0z

And fat32 doesn’t support files larger than 4GiB, which is why backup is failing.

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

[AnotherElk]

@Stefan

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

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.

[grumpy]

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!

[AnotherElk]

@grumpy

Be aware: I ran into createTarFork() ERROR 255 on restore as well.

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).

[grumpy]

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.

[Stefan]

@AnotherElk

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

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

Filesystem: it's possible ext4 on sd-card?

exFAT compatibility on /e/?

[NicoM]

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

[CosmoSteve]

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.

[Stefan]

Here you are:

FP3/FP3+ Fairphone OS updates - changelog & download links

Here you can find the official FP3(+). Fairphone OS release notes Android 11 releases (FP3/FP3+): 8901.4.A.0021.0 Release Date : 2023.02.13 Security Patch Level: 5th February, 2023 Change log: Camera improvements Applies only to Fairphone 3+ or Fairphone 3 with a Camera+ Module installed: More natural tones and exposure across modes (E.g. HDR, Portrait, Pro). Better image sharpness and noise filtering. Reduced motion blur for indoor scenes. Pro mode now has a separate configu…

[AnotherElk]

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 …

FP3 A.0118, Android9 OS update, security patchlevel April 5th, 2020

There are already several posts regarding this in the forum, there is no /sbin/update_engine_sideload in the boot image. I think Fairphone needs to enable something in the build process for this to work.

[k4y0z]

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.

[CosmoSteve]

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.

[k4y0z]

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.

[_tmp]

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

[_tmp]

Replying myself after reading a bit into the source:

@_tmp

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)

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

[CosmoSteve]

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

[lklaus]

I flashed them with fastboot and everything just worked

[CosmoSteve]

Thanks for the response! I just flashed them via fastboot, and just as a heads up, eventually everything worked. However, immediatly after flashing, I was greeted by something really spooky:

Only 3 white lines appeared. However, the device was still being found by fastboot, and after a second reboot into bootloader I saw this:

Those yellow stripes are no artefact of the camera, that’s what it really looked like.

But, after another reboot into bootloader, I saw the familiar screen, and was able to boot the phone normally.

But damn, that was scary. If anyone knows what that was, I’m eager to learn.

[AnotherElk]

I’m so glad somebody else encountered some funny Fastboot Mode and made pictures .
I didn’t take pictures, sadly, but I so far had:

• some really nice vertical coloured stripes in the background, mostly out of the blue-ish and red-ish range, fancily fading off the screen after a while.
• the same stripes only in shades of green, fancily reacting to touch on the touchscreen (I think, but could have been some other input, too, it’s been a while), and there to stay.
• the whole screen colour inverted.

… and every time accompanying a perfectly fine working Fastboot Mode.
With the stripes I thought “Ok, easter eggs perhaps.”, but the colour inversion was a bit bland compared to the nice stripes .

Edit: New instances of funny, but working Fastboot Mode for me …

• the screen content flipped upside down
• totally black screen, no text or anything

[CosmoSteve]

I’m glad to hear that I’m not the only one to have those! Do you think this might have something to do with how fast the phone was rebooted into fastboot after flashing it? Because this time, the flashing and rebooting process happened faster than ever before for me (I used that one flashing script floating around here).

I don’t understand the inner workings of the phone, but I can imagine that after flashing around and rebooting too quickly, some parts could still hold charges or not be properly reset, resulting in those glitches.