Indeed, that’s what I tried. And it worked! To my great relieve, I was just able to unlock_critical and unlock again and flash the /e/OS image afterwards and boot again.
So we should now wait for the next release of /e/OS/ and then could try locking again? Still these 4 days difference are very confusing, I’d suggest adding this explicitly to the FP6 installation documentation of /e/OS, even though there is this red warning already, just to make it explicit helping others not to do it like this.
Thanks for the help and pointing to Repair Services, luckily I didn’t need them in the end.
The current instructions are very clear and give the right amount of detail and examples on what is the anti-rollback mechanism and how to deal with it properly.
As said also in those instructions; there are risks; that is why Murena sells some phone pre-installed.
I agree the current instructions are very good. I definitely should have been more cautious.
One small suggestion from my side would be to make it even better by slightly modifying the first example. Currently Example 1 reads:
Your FP6 with Google Android has a Security Patch Level saying June 5, 2025
The /e/OS build available says: /e/OS build : A15 official (Security patch: 2025-05-05)
If here the example Security patch date would be modified to 2025-06-01 (or update both dates for the October case), it would be evident that even a 4 days older patch date matters, and triggers anti-rollback.
After all, wouldn’t it be likely that similar date pairs would occur again in the future? I mean, a new FP6 might have the patch from the same month as the latest /e/OS, and FairphoneOS seems to have it usually dated the 5th of the month, whereas /e/OS tends to have it dated the first of the month.