/e/OS being based on LineageOS, and LineageOS providing an Android 15 (Lineage 22) version for the Fairphone 3/3+, I am simply wondering if there is a chance that /e/OS will ever update to it?
My uninformed intuition is that if /e/OS did not update to Lineage 21 for the FP3, it likely won’t update to Lineage 22.
Is there a technical reason to that, or is it a lack of resources? And would it be possible for me to port it, or is it generally a lot of work? I don’t know how much /e/OS modifies from LineageOS that would potentially conflict.
I didn’t know about this list! Thank you! Also I thought that the FP3/3+ was an “Official” build (I bought my Fairphone with /e/OS), but apparently it’s “Community”.
I see that to upgrade to a community build, I need to install it manually. Do I then get OTA updates like with official builds, or do I have to manually reinstall for every update?
There are Different Build Types FP3 comes with official like yours and also there are community builds for self install linked above.
Both builds expect to receive monthly updates of /e/OS version. community builds require manual Android version upgrade.
Only official builds receive OTA Android version upgrade but it is only delivered after the upcoming Android version has “matured” a bit.
A so-called OTA upgrade to a new Android version (over the air, via the updater) should come to FP3 official somewhen, hopefully, if you just wait, most probably from Android 13 directly to 15 then …
The disadvantage of the community build is that you can’t lock the bootloader, which may prevent some apps from working properly. I would not recommend switching from Official to Community.
I would like to understand that: when installing a custom ROM, I understand there may be two warnings when booting the phone:
One saying that the bootloader is unlocked
One saying it’s a “custom OS”
In order to relock the bootloader, I thought that I would have to enter the signing key somewhere through fastboot. Isn’t that what /e/OS does? Can’t I “just” add the /e/OS dev keys when I install the community build?
What is needed in order to not have the second one (“custom OS”)? Does /e/OS have some partnership with Fairphone for that?
This is a requirement imposed on manufactures to verify boot. The “verification”, if “imperfect”, must be communicated to users by the mentioned colour coded warnings. This requirement is at a higher level than any relationship between /e/ and Fairphone.
This is done automatically on official builds.
community builds are of a build variant which do not support locking.
It should be possible to build /e/ for yourself and self sign but I never tried it.
My understanding is that on some devices (I assume the Fairphone is included), it’s possible to set a user root of trust from the signing key (here key.pem):
So I was thinking that maybe /e/OS could make this pkmd.bin available for the community builds . Isn’t that true?
But then the root of trust is set by the user and therefore it warns about it for 10 seconds when booting the phone, as per the diagram below:
And somehow I don’t have this warning on my /e/OS FP3, so maybe it means that /e/OS got Fairphone to add their key as a “system” root of trust?
I really would like to understand that but I don’t find much documentation from /e/OS about it. I even read some Reddit thread where someone was saying that /e/OS was using the android testing key (to avoid the warning messages) and that it made the secure boot completely useless.
Well there is no warning showing up when I boot my phone, so it looks like it’s locked. My question is: how does /e/OS make it so? Is there an agreement with Fairphone to set the signing key as a trusted root?
Well, I would like to understand what it would mean for me to use a community build instead of the official build.
Respectfully, I feel like you are making assumptions here. I can make them as well, but I would like to know how it actually is (not how it looks like it may be) .
There are also a few phones (like the original Pixel/XL and OnePlus phones like the 5/5t and older) that don’t support AVB v2, but can have their bootloaders relocked because they simply never check to see if the OS is signed by the vendor, just that it has some valid signature on it.
[…]
The FP3 falls into this category as well.
Which would explain why I don’t have a warning (not even “custom OS”) running /e/OS on my FP3+.
But then here on the Fairphone forums some say that the FP3+ accepts the testing keys as built-in root of trust, which would mean that the secure boot is completely useless anyway.
So yeah… because I get no warning doesn’t seem to mean that my secure boot actually works .
So I downloaded the latest official /e/OS image and verified the signature as described in the fairphone post:
% python verify_signature.py --file boot.img --vbmeta vbmeta.img
Boot Signature Tool v1.6 (c) B.Kerler 2017-2019
----------------------------------------------
Kernel=0x00000800, length=0x00B8E800
Ramdisk=0x00B8F000, length=0x00BBB800
Second=0x0174A800, length=0x00000000
QCDT=0x0174A800, length=0x00000800
Signature start=0x0174B000
AVB >=2.0 vbmeta detected: avbtool 1.2.0
----------------------------------------
Image-Target: boot
Salt: e61ca4c0890e9070de01dfe28eb2c57596e3d4a83ab6270e2b12aebdf6213a11
Image-Size: 0x174a800
Calced Image-Hash: 6a0fc48b7dcf36d23ebfd126ad1c62432a6da9391d082eff5d306383ac0355d9
Image-Hash: 6a0fc48b7dcf36d23ebfd126ad1c62432a6da9391d082eff5d306383ac0355d9
VBMeta-Image-Hash: 6a0fc48b7dcf36d23ebfd126ad1c62432a6da9391d082eff5d306383ac0355d9
Signature-RSA-Modulus (n): d804afe3d3846c7e0d893dc28cd31255e962c9f10f5ecc1672ab447c2c654a94b5162b00bb06ef1307534cf964b9287a1b849888d867a423f9a74bdc4a0ff73a18ae54a815feb0adac35da3bad27bcafe8d32f3734d6512b6c5a27d79606af6bb880cafa30b4b185b34daaaac316341ab8e7c7faf90977ab9793eb44aecf20bcf08011db230c4771b96dd67b604787165693b7c22a9ab04c010c30d89387f0ed6e8bbe305bf6a6afdd807c455e8f91935e44feb88207ee79cabf31736258e3cdc4bcc2111da14abffe277da1f635a35ecadc572f3ef0c95d866af8af66a7edcdb8eda15fba9b851ad509ae944e3bcfcb5cc97980f7cca64aa86ad8d33111f9f602632a1a2dd11a661b1641bdbdf74dc04ae527495f7f58e3272de5c9660e52381638fb16eb533fe6fde9a25e2559d87945ff034c26a2005a8ec251a115f97bf45c819b184735d82d05e9ad0f357415a38e8bcc27da7c5de4fa04d3050bba3ab249452f47c70d413f97804d3fc1b5bb705fa737af482212452ef50f8792e28401f9120f141524ce8999eeb9c417707015eabec66c1f62b3f42d1687fb561e45abae32e45e91ed53665ebdedade612390d83c9e86b6c2da5eec45a66ae8c97d70d6c49c7f5c492318b09ee33daa937b64918f80e6045c83391ef205710be782d8326d6ca61f92fe0bf0530525a121c00a75dcc7c2ec5958ba33bf0432e5edd00db0db33799a9cd9cb743f7354421c28271ab8daab44111ec1e8dfc1482924e836a0a6b355e5de95ccc8cde39d14a5b5f63a964e00acb0bb85a7cc30be6befe8b0f7d348e026674016cca76ac7c67082f3f1aa62c60b3ffda8db8120c007fcc50a15c64a1e25f3265c99cbed60a13873c2a45470cca4282fa8965e789b48ff71ee623a5d059377992d7ce3dfde3a10bcf6c85a065f35cc64a635f6e3a3a2a8b6ab62fbbf8b24b62bc1a912566e369ca60490bf68abe3e7653c27aa8041775f1f303621b85b2b0ef8015b6d44edf71acdb2a04d4b421ba655657e8fa84a27d130eafd79a582aa381848d09a06ac1bbd9f586acbd756109e68c3d77b2ed3020e4001d97e8bfc7001b21b116e741672eec38bce51bb4062331711c49cd764a76368da3898b4a7af487c8150f3739f66d8019ef5ca866ce1b167921dfd73130c421dd345bd21a2b3e5df7eaca058eb7cb492ea0e3f4a74819109c04a7f42874c86f63202b462426191dd12c316d5a29a206a6b241cc0a27960996ac476578685198d6d8a62da0cfece274f282e397d97ed4f80b70433db17b9780d6cbd719bc630bfd4d88fe67acb8cc50b768b35bd61e25fc5f3c8db1337cb349013f71550e51ba6126faeae5b5e8aacfcd969fd6c15f5391ad05de20e751da5b9567edf4ee426570130b70141cc9e019ca5ff51d704b6c0674ecb52e77e174a1a399a0859ef1acd87e
Signature-n0inv: 1440285869
!!!! Image seems to be signed by google test keys, yay !!!!
AVB-Status: VERIFIED, 0
Which seems to confirm that the official image is signed with the Google test keys, right? Which sounds like it makes the secure boot useless in any case.
Now checking the latest community image:
% python verify_signature.py --file boot.img --vbmeta vbmeta.img
Boot Signature Tool v1.6 (c) B.Kerler 2017-2019
----------------------------------------------
Kernel=0x00000800, length=0x00C34000
Ramdisk=0x00C34800, length=0x00D76800
Second=0x019AB000, length=0x00000000
QCDT=0x019AB000, length=0x00000800
Signature start=0x019AB800
AVB >=2.0 vbmeta detected: avbtool 1.3.0
----------------------------------------
Image-Target: boot
Salt: 3dbb967a39cc880e5ab792dbf7150565fc7cdfa4bd057325d0f5ed28e829f765
Image-Size: 0x19ab000
Calced Image-Hash: 1aecd52e1fd0123fe76decd44500e496dc289697fa2aed79edd393079b902020
Image-Hash: 1aecd52e1fd0123fe76decd44500e496dc289697fa2aed79edd393079b902020
VBMeta-Image-Hash: 1aecd52e1fd0123fe76decd44500e496dc289697fa2aed79edd393079b902020
Signature-RSA-Modulus (n): d804afe3d3846c7e0d893dc28cd31255e962c9f10f5ecc1672ab447c2c654a94b5162b00bb06ef1307534cf964b9287a1b849888d867a423f9a74bdc4a0ff73a18ae54a815feb0adac35da3bad27bcafe8d32f3734d6512b6c5a27d79606af6bb880cafa30b4b185b34daaaac316341ab8e7c7faf90977ab9793eb44aecf20bcf08011db230c4771b96dd67b604787165693b7c22a9ab04c010c30d89387f0ed6e8bbe305bf6a6afdd807c455e8f91935e44feb88207ee79cabf31736258e3cdc4bcc2111da14abffe277da1f635a35ecadc572f3ef0c95d866af8af66a7edcdb8eda15fba9b851ad509ae944e3bcfcb5cc97980f7cca64aa86ad8d33111f9f602632a1a2dd11a661b1641bdbdf74dc04ae527495f7f58e3272de5c9660e52381638fb16eb533fe6fde9a25e2559d87945ff034c26a2005a8ec251a115f97bf45c819b184735d82d05e9ad0f357415a38e8bcc27da7c5de4fa04d3050bba3ab249452f47c70d413f97804d3fc1b5bb705fa737af482212452ef50f8792e28401f9120f141524ce8999eeb9c417707015eabec66c1f62b3f42d1687fb561e45abae32e45e91ed53665ebdedade612390d83c9e86b6c2da5eec45a66ae8c97d70d6c49c7f5c492318b09ee33daa937b64918f80e6045c83391ef205710be782d8326d6ca61f92fe0bf0530525a121c00a75dcc7c2ec5958ba33bf0432e5edd00db0db33799a9cd9cb743f7354421c28271ab8daab44111ec1e8dfc1482924e836a0a6b355e5de95ccc8cde39d14a5b5f63a964e00acb0bb85a7cc30be6befe8b0f7d348e026674016cca76ac7c67082f3f1aa62c60b3ffda8db8120c007fcc50a15c64a1e25f3265c99cbed60a13873c2a45470cca4282fa8965e789b48ff71ee623a5d059377992d7ce3dfde3a10bcf6c85a065f35cc64a635f6e3a3a2a8b6ab62fbbf8b24b62bc1a912566e369ca60490bf68abe3e7653c27aa8041775f1f303621b85b2b0ef8015b6d44edf71acdb2a04d4b421ba655657e8fa84a27d130eafd79a582aa381848d09a06ac1bbd9f586acbd756109e68c3d77b2ed3020e4001d97e8bfc7001b21b116e741672eec38bce51bb4062331711c49cd764a76368da3898b4a7af487c8150f3739f66d8019ef5ca866ce1b167921dfd73130c421dd345bd21a2b3e5df7eaca058eb7cb492ea0e3f4a74819109c04a7f42874c86f63202b462426191dd12c316d5a29a206a6b241cc0a27960996ac476578685198d6d8a62da0cfece274f282e397d97ed4f80b70433db17b9780d6cbd719bc630bfd4d88fe67acb8cc50b768b35bd61e25fc5f3c8db1337cb349013f71550e51ba6126faeae5b5e8aacfcd969fd6c15f5391ad05de20e751da5b9567edf4ee426570130b70141cc9e019ca5ff51d704b6c0674ecb52e77e174a1a399a0859ef1acd87e
Signature-n0inv: 1440285869
!!!! Image seems to be signed by google test keys, yay !!!!
AVB-Status: VERIFIED, 0
Again, it looks like it’s signed with the Google test keys, making the secure boot useless. But it also means that I should (if my understanding is correct) be able to use the community build and “relock” the bootloader (which was a valid concern raised by @MRTN above ).
/e/OS updates for devices like the Fairphone 3/3+ often lag behind LineageOS due to limited development resources, testing overhead, and the need to integrate their own de-Googled services and apps, which adds complexity. If /e/OS skipped LineageOS 21, it’s uncertain they’ll jump to 22 unless there’s significant demand or volunteer support. Technically, porting it yourself is possible but involves a fair amount of work—merging /e/OS changes, ensuring MicroG and other services work, and debugging compatibility issues—so it’s doable but time-intensive unless you’re already experienced with Android ROM development.
that’s the lore, FP3 being useless for relock (irrespective or on top of of /e/OS images signed by google test-keys) because you can overwrite keys in EDL/QDL mode easily. But as to the flow of the diagram you posted before: you can just flash other warning screens if you’re not an OEM needing the Google stamp (as in, certification).
As to the OP question: there’s a testing channel and links to ota images with A15 for the FP3 and yes, I’d say the delay is always due to capacity
. Isn’t that true?
.
.
).