Install /e/ on a Fairphone FP4 - “FP4” (beta)

Good morning :person_raising_hand:

In the end you are right and …

O M F G
what can I say?
I did it after reading the repartition-Link.
And it worked a 100% like a charm (or how do I say it correctly?).
Why are you @hirnsushi not an Fairphone-Angel?
In the end you also helped @bookworm, too in repartitioning.

Anyway, the outputs (just for the protocol), Success:

But first I set the path variable to my adb-platform-folder, so that I didn’t have to replace the path to IMG-Files and I was able to copy/paste the commands from the Howto.

I started by booting into the bootloader and rebooted into it again, just to make sure, that the commands are working with the new path entry.

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot reboot bootloader
Rebooting into bootloader                          OKAY [  0.001s]
Finished. Total time: 0.006s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash bluetooth_a bluetooth.img
Sending 'bluetooth_a' (940 KB)                     OKAY [  0.030s]
Writing 'bluetooth_a'                              OKAY [  0.005s]
Finished. Total time: 0.077s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash bluetooth_b bluetooth.img
Sending 'bluetooth_b' (940 KB)                     OKAY [  0.029s]
Writing 'bluetooth_b'                              OKAY [  0.005s]
Finished. Total time: 0.075s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash devcfg_a devcfg.img
Sending 'devcfg_a' (42 KB)                         OKAY [  0.012s]
Writing 'devcfg_a'                                 OKAY [  0.002s]
Finished. Total time: 0.043s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash devcfg_b devcfg.img
Sending 'devcfg_b' (42 KB)                         OKAY [  0.004s]
Writing 'devcfg_b'                                 OKAY [  0.002s]
Finished. Total time: 0.026s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash dsp_a dsp.img
Sending 'dsp_a' (65536 KB)                         OKAY [  1.613s]
Writing 'dsp_a'                                    OKAY [  0.139s]
Finished. Total time: 1.803s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash dsp_b dsp.img
Sending 'dsp_b' (65536 KB)                         OKAY [  1.559s]
Writing 'dsp_b'                                    OKAY [  0.171s]
Finished. Total time: 1.775s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash modem_a modem.img
Sending 'modem_a' (146188 KB)                      OKAY [  3.665s]
Writing 'modem_a'                                  OKAY [  0.331s]
Finished. Total time: 4.057s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash modem_b modem.img
Sending 'modem_b' (146188 KB)                      OKAY [  3.566s]
Writing 'modem_b'                                  OKAY [  0.360s]
Finished. Total time: 3.971s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash xbl_a xbl.img
Sending 'xbl_a' (3298 KB)                          OKAY [  0.090s]
Writing 'xbl_a'                                    OKAY [  0.013s]
Finished. Total time: 0.165s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash xbl_b xbl.img
Sending 'xbl_b' (3298 KB)                          OKAY [  0.084s]
Writing 'xbl_b'                                    OKAY [  0.011s]
Finished. Total time: 0.134s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash tz_a tz.img
Sending 'tz_a' (2944 KB)                           OKAY [  0.076s]
Writing 'tz_a'                                     OKAY [  0.011s]
Finished. Total time: 0.126s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash tz_b tz.img
Sending 'tz_b' (2944 KB)                           OKAY [  0.077s]
Writing 'tz_b'                                     OKAY [  0.011s]
Finished. Total time: 0.130s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash hyp_a hyp.img
Sending 'hyp_a' (399 KB)                           OKAY [  0.021s]
Writing 'hyp_a'                                    OKAY [  0.004s]
Finished. Total time: 0.067s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash hyp_b hyp.img
Sending 'hyp_b' (399 KB)                           OKAY [  0.019s]
Writing 'hyp_b'                                    OKAY [  0.004s]
Finished. Total time: 0.048s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash keymaster_a keymaster.img
Sending 'keymaster_a' (257 KB)                     OKAY [  0.015s]
Writing 'keymaster_a'                              OKAY [  0.004s]
Finished. Total time: 0.053s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash keymaster_b keymaster.img
Sending 'keymaster_b' (257 KB)                     OKAY [  0.011s]
Writing 'keymaster_b'                              OKAY [  0.004s]
Finished. Total time: 0.049s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash abl_a abl.img
Sending 'abl_a' (148 KB)                           OKAY [  0.011s]
Writing 'abl_a'                                    OKAY [  0.004s]
Finished. Total time: 0.045s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash abl_b abl.img
Sending 'abl_b' (148 KB)                           OKAY [  0.012s]
Writing 'abl_b'                                    OKAY [  0.004s]
Finished. Total time: 0.033s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash boot_a boot.img
Sending 'boot_a' (98304 KB)                        OKAY [  2.424s]
Writing 'boot_a'                                   OKAY [  0.221s]
Finished. Total time: 2.697s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash boot_b boot.img
Sending 'boot_b' (98304 KB)                        OKAY [  2.373s]
Writing 'boot_b'                                   OKAY [  0.231s]
Finished. Total time: 2.666s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash recovery_a recovery.img
Sending 'recovery_a' (98304 KB)                    OKAY [  2.474s]
Writing 'recovery_a'                               OKAY [  0.231s]
Finished. Total time: 2.762s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash recovery_b recovery.img
Sending 'recovery_b' (98304 KB)                    OKAY [  2.409s]
Writing 'recovery_b'                               OKAY [  0.243s]
Finished. Total time: 2.689s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash dtbo_a dtbo.img
Sending 'dtbo_a' (24576 KB)                        OKAY [  0.616s]
Writing 'dtbo_a'                                   OKAY [  0.056s]
Finished. Total time: 0.730s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash dtbo_b dtbo.img
Sending 'dtbo_b' (24576 KB)                        OKAY [  0.596s]
Writing 'dtbo_b'                                   OKAY [  0.057s]
Finished. Total time: 0.691s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash vbmeta_system_a vbmeta_system.img
Sending 'vbmeta_system_a' (4 KB)                   OKAY [  0.012s]
Writing 'vbmeta_system_a'                          OKAY [  0.002s]
Finished. Total time: 0.063s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash vbmeta_system_b vbmeta_system.img
Sending 'vbmeta_system_b' (4 KB)                   OKAY [  0.006s]
Writing 'vbmeta_system_b'                          OKAY [  0.002s]
Finished. Total time: 0.051s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash vbmeta_a vbmeta.img
Sending 'vbmeta_a' (8 KB)                          OKAY [  0.002s]
Writing 'vbmeta_a'                                 OKAY [  0.001s]
Finished. Total time: 0.021s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash vbmeta_b vbmeta.img
Sending 'vbmeta_b' (8 KB)                          OKAY [  0.009s]
Writing 'vbmeta_b'                                 OKAY [  0.002s]
Finished. Total time: 0.044s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash super super.img
Sending sparse 'super' 1/4 (780797 KB)             OKAY [ 20.677s]
Writing 'super'                                    OKAY [  0.002s]
Sending sparse 'super' 2/4 (751633 KB)             OKAY [ 27.026s]
Writing 'super'                                    OKAY [  0.002s]
Sending sparse 'super' 3/4 (726194 KB)             OKAY [ 19.988s]
Writing 'super'                                    OKAY [  0.002s]
Sending sparse 'super' 4/4 (586888 KB)             OKAY [ 22.007s]
Writing 'super'                                    OKAY [  0.002s]
Finished. Total time: 91.259s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash aop_a aop.img
Sending 'aop_a' (174 KB)                           OKAY [  0.016s]
Writing 'aop_a'                                    OKAY [  0.004s]
Finished. Total time: 11.880s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash aop_b aop.img
Sending 'aop_b' (174 KB)                           OKAY [  0.011s]
Writing 'aop_b'                                    OKAY [  0.004s]
Finished. Total time: 0.037s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash featenabler_a featenabler.img
Sending 'featenabler_a' (84 KB)                    OKAY [  0.005s]
Writing 'featenabler_a'                            OKAY [  0.003s]
Finished. Total time: 0.034s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash featenabler_b featenabler.img
Sending 'featenabler_b' (84 KB)                    OKAY [  0.006s]
Writing 'featenabler_b'                            OKAY [  0.004s]
Finished. Total time: 0.028s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash imagefv_a imagefv.img
Sending 'imagefv_a' (524 KB)                       OKAY [  0.022s]
Writing 'imagefv_a'                                OKAY [  0.004s]
Finished. Total time: 0.057s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash imagefv_b imagefv.img
Sending 'imagefv_b' (524 KB)                       OKAY [  0.021s]
Writing 'imagefv_b'                                OKAY [  0.004s]
Finished. Total time: 0.064s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash multiimgoem_a multiimgoem.img
Sending 'multiimgoem_a' (13 KB)                    OKAY [  0.009s]
Writing 'multiimgoem_a'                            OKAY [  0.002s]
Finished. Total time: 0.044s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash multiimgoem_b multiimgoem.img
Sending 'multiimgoem_b' (13 KB)                    OKAY [  0.011s]
Writing 'multiimgoem_b'                            OKAY [  0.001s]
Finished. Total time: 0.039s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash qupfw_a qupfw.img
Sending 'qupfw_a' (53 KB)                          OKAY [  0.010s]
Writing 'qupfw_a'                                  OKAY [  0.003s]
Finished. Total time: 0.041s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash qupfw_b qupfw.img
Sending 'qupfw_b' (53 KB)                          OKAY [  0.008s]
Writing 'qupfw_b'                                  OKAY [  0.002s]
Finished. Total time: 0.028s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash uefisecapp_a uefisecapp.img
Sending 'uefisecapp_a' (121 KB)                    OKAY [  0.012s]
Writing 'uefisecapp_a'                             OKAY [  0.003s]
Finished. Total time: 0.068s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash uefisecapp_b uefisecapp.img
Sending 'uefisecapp_b' (121 KB)                    OKAY [  0.012s]
Writing 'uefisecapp_b'                             OKAY [  0.003s]
Finished. Total time: 0.035s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash xbl_config_a xbl_config.img
Sending 'xbl_config_a' (94 KB)                     OKAY [  0.007s]
Writing 'xbl_config_a'                             OKAY [  0.006s]
Finished. Total time: 0.039s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash xbl_config_b xbl_config.img
Sending 'xbl_config_b' (94 KB)                     OKAY [  0.009s]
Writing 'xbl_config_b'                             OKAY [  0.004s]
Finished. Total time: 0.032s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash core_nhlos_a core_nhlos.img
Sending 'core_nhlos_a' (108556 KB)                 OKAY [  2.751s]
Writing 'core_nhlos_a'                             OKAY [  0.263s]
Finished. Total time: 3.066s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot flash core_nhlos_b core_nhlos.img
Sending 'core_nhlos_b' (108556 KB)                 OKAY [  2.623s]
Writing 'core_nhlos_b'                             OKAY [  0.250s]
Finished. Total time: 2.923s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot erase userdata
******** Did you mean to fastboot format this ext4 partition?
Erasing 'userdata'                                 OKAY [  0.733s]
Finished. Total time: 0.762s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot erase metadata
Erasing 'metadata'                                 OKAY [  0.018s]
Finished. Total time: 0.034s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot --set-active=a
Setting current slot to 'a'                        OKAY [  0.027s]
Finished. Total time: 0.041s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot.exe getvar current-slot
current-slot: a
Finished. Total time: 0.006s

c:\IMG-e-1.4-r-20220920220047-stable-FP4>fastboot reboot
Rebooting                                          OKAY [  0.000s]
Finished. Total time: 0.008s

It was easier than the easy-installer from /e/os website, I’m gonna delete it :wink:
The whole install-procedure via CMD took less time than uninstalling easy-installer. :+1:

Thank you, Thank you, Thank you.
It started up without any errors.

Best regards
Salsa

4 Likes

There’s a local aspect to it, “heavens” usually get assigned to (bigger) cities, I live in the middle of nowhere at the edge of the alps. And I also hate answering emails :smirk:

That’s great news :tada:
I hope you have fun with your new /e/ installation :slightly_smiling_face:

Just out of curiosity, could you check fastboot flashing get_unlock_ability, it’s always interesting to see if the reset still happens.

1 Like

the Internet connects us all on the small planet; City hin oder her :rofl:
and answering a forums post so fast is kinda the same like answering an e-Mail, but everyone can participate on the experience. Isn’t that what makes a good community?; sharing know-how, errors and success?!? :thinking:

Sure, I’ll take a look, it’s perfectly set to 1.
grafik
Also within bootloader, written down in red says: DEVICE STATE - unlocked.
But as we said I skipped the last part from /e/os manual, locking the bootloader.

And also, like you said it’s true. The OEM-Switch mentioned above is not grayed out in /e/os.
So this could cause a problem. Maybe that should be grayed out from any running OS, if bootloader is unlocked, just for security reason.

Yep, that’s my reasoning as well. I’m just a user, my knowledge is limited, that way others with more experience can always chime in, and together we’ll hopefully end up with a solution :slightly_smiling_face:

That’s great, maybe the bug finally is behind us :crossed_fingers:

They did that on purpose, so people who’s get_unlock_ability got reset can just turn it back ON before locking the bootloader.

1 Like

The idea of Angels is to get local and personal help if needed, beside the on-line help already offered here in the forum.

2 Likes

Thanks for all the clarifications, @hirnsushi.

I am still a little bit puzzled regarding the anti-rollback protection and the security patch level (specified by date), though:

  • My phone has still version FP4.FP4D.A.163.20220826 installed. Hence the security patch level is, like it has been already mentioned, August 5th 2022.
  • According to /e/OS’s release notes, the current version is 1.4-r and includes security patches “until August”. There is a link to Google’s official security bulletin site pointing to August 1st 2022:

    This /e/OS v1.4 includes the Android security patches available until August. More information in the link below.
    Android security patch August

  • I am not familiar with Google’s security patch schedule, but it seems there are two every month: at the first day, and at the fifth day. Is this something I need distinguish in this regard?

I am pretty much assume, that /e/OS in fact includes the security patches up to August 5th. But I still do feel uncomfortable since it is not mentioned explicitly.
To my understanding, there is never an issue as long as the bootloader is not relocked by myself. I want to know that nevertheless.

Just to be sure: Is it possible to brick the phone while locking the bootloader, even if you ensure everytime that the OEM unlock capability is activated (i.e. fastboot flashing get_unlock_ability returns 1)?
As long as this is active, it is always possible to execute fastboot flashing unlock[_critical], isn’t it?

It seems there is no way to check if anti-rollback protection would kick-in in advance to locking the bootloader. It sound like this would be super useful.

Welcome to the community :wave:

The interesting information isn’t in the /e/ release notes, but in the commit history of the FP4 specific repo. If you have a look at the bottom of this merge request, you can see, that A.163 has been released in 1.4, while A.170 is planned for 1.5.
The important part is, does your phone match the firmware patch level, which seems to be the case :+1:

Since Fairphone has never actually told us anything about the specifics of the bootloader bug, I’d say, there’s always a possibility. But you are probably asking the wrong person, past experiences on this forum have made me a bit overly cautious. (And I’m running Magisk, so I can’t lock it anyway :man_shrugging:)
Generally you should be fine, others have been able to just unlock their bootloader after a failed attempt, but I can’t guarantee it.

1 Like

I’m using the newest version of eOS. If this could help you, I share this the system information.

2 Likes

Thanks for your answers.

Now confident that I a) won’t brick it with and b) the security patch level should match, I tried it and I can confirm that 1.4-r contains security patches up to 2022-08-05. Thanks @jobal and @hirnsushi!

The remaining part is only because im curious: :slight_smile:

@hirnsushi, I feel a bit stupid that I did not think about looking into the commits by myself :slight_smile:
Let’s see: Starring at MR!21, it seems the relevant data is the change from 2022-08-05 to 2022-09-05 and that this change is linked to milestone /e/OS v1.5-beta. That essential means that the prior version, i.e. 1.4-r, contains security patches up to 2022-08-05.
It’s seems odd that this repository does not contain a tag 1.4-r. Looking at the corresponding file content would show this information directly.
Listing the history of the file android_device_fairphone_FP4:BoardConfig.mk lists the changes to the security patch date. Jumping to the corresponding change to the actual MR reveals again the assigned milestone (!19 in case of 1.4-r).
Fine.

One thing I did not expect, but confuses me – and I guess there is something I have missed: the version string mentioned by the /e/ developer, i.e. FP4.FP4D.A.163.20220826 or FP4.FP4G.A.170.20220920, is indeed the very same as used by Fairphone. They “bump” to the Fairphone version. I assumed this would be the Fairphone’s firmware version. Is it something different? I guess it just means /e/ aligned its firmware to that one e.g. in respect of the security patch date.

I was not able to draw the line between the manifest of 1.4-r (which seems to be that version of default.xml) to the specific version of the android_device_fairphone_FP4 repository. Mh, shouldn’t it be there?

There are different patch levels, one is the security updates Google releases and the other are the vendor / firmware patches Fairphone releases. When you see a Fairhphone release pulled in, that means the proprietary blobs have been updated to match upstream (Fairphone in this case).
In newer Android versions the different patch levels are listed in even more detail, that’s what it looks like on my FP4 running A13:

I have absolutely no idea how the /e/ project is structured, you might want to ask one of the devs on their forum:

1 Like

Do you know if anti-rollback protection looks at all these dates or if it only takes e.g. the vendor security patch level into account?

Below are some findings and my understanding how the anti-rollback protection works. Feel free to ignore. It’s slightly out of toic I guess. :see_no_evil:

To my understanding, the anti-rollback feature is configured by the mobile phone vendor (in this case Fairphone) and utilises write-once memory (or similar, called fuses) of the SoC. The process is standardised as part of Android Verified Boot (AVB). It is basically a index updated during flashing and it is not allowed to decrement. Since its is is cryptically signed, you can’t tamper with it.
I assume that the root of trust, i.e. key0 from the linked documentation, is rolled out by the mobile phone vendor (i.e. Fairphone in this case) during production. I guess this vendor also predetermines when increments to the rollback index are expected to happen. Perhaps this is even already specified by AVB.

An interesting question is which party actually signs the rollback index in case of /e/OS. Does Fairphone B.V. assess the image and provide the signature? Does the /e/ foundation own a (derived) key and is capable doing it itself?
This signing party seems to be in charge to deduce the rollback index from the security patch level (dates) and hence “controls” which of these dates are taken into account.

Further reading of the linked documentation reveals that it is possible that several “partitions” contain different rollback indices. Perhaps my assumption that hardware fuses are used directly here is wrong and it is only the backing feature to protect the bootloader, EDL or whatsoever and the actual “firmware rollback protection” based on the security patch levels is designed on top of that in SW.

Quote from the linked documentation:

If verification keys (note: these verify the rollback index) are mutable they must only be set by the end user, e.g. it must never be set at the factory or store or any intermediate point before the end user. Additionally, it must only be possible to set or clear a key while the device is in the UNLOCKED state.

Interesting. Is this used to support custom ROMs and does /e/OS fall under this category in this regard?

Puh – exhausting topic … :wink:
I am sorry if I misuse this topic inappropriately. My aim is to get a deeper understanding how anti-rollback protection actually works to understand better, how to avoid triggering eventually.
Just let me know if I drift too far off-topic.

Maybe you can find some information here

1 Like

Can’t understand your latest post, I apologize. But you write

in your previous, so I am curious: have you also locked your bootloader after install eOS?
I was lucky in my first attempt to install /e/ and locked it, so now I don’t have a rooted device and all my daily apps (banking, identification, tracking…) work well.

Sorry for not beeing clear enough:
What I have tried was to install /e/OS 1.4.-r over the FP4.FP4D.A.163.20220826 which was succesful. I did keep keep the bootloader unlocked (for now), as well as the “OEM unlock” switch.
So essentially, nothing new :wink:

Thanks.
There are quite “irritating” facts in that thread :stuck_out_tongue:
(I am referring to the used test keys for signing the bootloader.)

Kind of, but from my very limited understanding not completely right.
A custom ROM doesn’t really have to make use of AVB, which pulls in rollback protection. You can just keep the bootloader unlocked and the whole issue goes away completely.

As you found out yourself, there’s the option of user-settable root of trust as well, which /e/OS, iodé, CalyOS etc. use to set their own keys and sign their releases with. That key gets loaded into “tamper evident” storage and makes it possible to lock the bootloader with one of those ROMs installed.

The specifics of AVB / rollback protection get set in the build system, so by whoever is building the images you are installing to your device. And the index gets updated when those images increment the index, e.g. during an OTA update.
You can have a look at that in action for example in the /e/OS BoardConfig.mk or the CalyxOS BoardConfig.mk.

If you use avbtool, you’ll see that reflected in the images:

avbtool output
foo@bar:$ ./avbtool.py info_image --image /home/foo/Development/Android/calyx/FP4-tp1a.221005.003/image-FP4-tp1a.221005.003/vbmeta_system.img 
Minimum libavb version:   1.0
Header Block:             256 bytes
Authentication Block:     576 bytes
Auxiliary Block:          2688 bytes
Public key (sha1):        29f859183d3f64db6652e498d30ab916662aef90
Algorithm:                SHA256_RSA4096
Rollback Index:           1662336000
Flags:                    0
Rollback Index Location:  0
Release String:           'avbtool 1.2.0'
Descriptors:
    Prop: com.android.build.system.os_version -> '13'
    Prop: com.android.build.system.fingerprint -> 'Fairphone/FP4eea/FP4:11/RKQ1.210503.001/FP4D:user/release-keys'
    Prop: com.android.build.system.security_patch -> '2022-08-05'
    Prop: com.android.build.product.os_version -> '13'
    Prop: com.android.build.product.fingerprint -> 'Fairphone/FP4eea/FP4:11/RKQ1.210503.001/FP4D:user/release-keys'
    Prop: com.android.build.product.security_patch -> '2022-08-05'
    Prop: com.android.build.system_ext.os_version -> '13'
    Prop: com.android.build.system_ext.fingerprint -> 'Fairphone/FP4eea/FP4:11/RKQ1.210503.001/FP4D:user/release-keys'
    Prop: com.android.build.system_ext.security_patch -> '2022-08-05'
    Hashtree descriptor:
      Version of dm-verity:  1
      Image Size:            1121902592 bytes
      Tree Offset:           1121902592
      Tree Size:             8839168 bytes
      Data Block Size:       4096 bytes
      Hash Block Size:       4096 bytes
      FEC num roots:         2
      FEC offset:            1130741760
      FEC size:              8945664 bytes
      Hash Algorithm:        sha1
      Partition Name:        product
      Salt:                  62d86d9743a5cc83ebef37719730ed9ac615603b23af7aadf19cf3e2029d488b
      Root Digest:           fc7c82592f04ef39be89bfa114a92db3da6b5434
      Flags:                 0
    Hashtree descriptor:
      Version of dm-verity:  1
      Image Size:            919646208 bytes
      Tree Offset:           919646208
      Tree Size:             7249920 bytes
      Data Block Size:       4096 bytes
      Hash Block Size:       4096 bytes
      FEC num roots:         2
      FEC offset:            926896128
      FEC size:              7331840 bytes
      Hash Algorithm:        sha1
      Partition Name:        system
      Salt:                  62d86d9743a5cc83ebef37719730ed9ac615603b23af7aadf19cf3e2029d488b
      Root Digest:           0f72873eeb1f9fc0f8df5026bbeba1fda7b4c5ec
      Flags:                 0
    Hashtree descriptor:
      Version of dm-verity:  1
      Image Size:            282202112 bytes
      Tree Offset:           282202112
      Tree Size:             2232320 bytes
      Data Block Size:       4096 bytes
      Hash Block Size:       4096 bytes
      FEC num roots:         2
      FEC offset:            284434432
      FEC size:              2252800 bytes
      Hash Algorithm:        sha1
      Partition Name:        system_ext
      Salt:                  62d86d9743a5cc83ebef37719730ed9ac615603b23af7aadf19cf3e2029d488b
      Root Digest:           a510cf9e25ba68c4cae0ef22524ea151074a807d
      Flags:                 0

Now, according to the docs

All user data must be cleared when transitioning from the LOCKED to the UNLOCKED state (including the userdata partition and any NVRAM spaces). Additionally all stored_rollback_index[n] locations must be cleared (all elements must be set to zero). Similar action (erasing userdata, NVRAM spaces, and stored_rollback_index[n] locations) shall also happening when transitioning from UNLOCKED to LOCKED

… all those indices should be cleared when transitioning between different states, why we still have to worry about the FPOS patch level when installing /e/OS is beyond me :man_shrugging:
You’ll have to talk to an actual developer if you need those answers, I’d be very curious as well.

2 Likes

It’s not your fault, but my english :face_with_open_eyes_and_hand_over_mouth:
Thanks for the replay.

1 Like

I’ve asked one of the CalyxOS developers, and yeah … :roll_eyes:

That’s exactly what we told Fairphone as well. The implementation is clearly broken.

(To be clear, that’s a general problem, not /e/OS specific)

1 Like

There’s now an Android 12 (S) /e/OS version available and so far it’s running fine on my FP4.

2 Likes

@hirnsushi, thanks a lot for the great references and insights!

1 Like