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.
I suggest to add something like this : “Sign out of your Google account before switching to /e/OS”, since this issue have been observed (there are several posts like this) :
Another thing I think it could be improved in the “Unlocking the bootloader” section :
5. Reboot on fastboot by running the command in the PC console adb reboot bootloader
Tip: All the console commands are run on an adb enabled PC and in the adb console.
6. Ask for unlock with fastboot flashing unlock
7. Approve with volume + then power
The device proceed with a factory reset, and automatically reboots
8. Reboot again into bootloader
This step 8 may (incorrectly) suggest that the user run the adb reboot bootloader command again, but after the first unlock, this is no longer possible (unless to setup the phone and activate again the developer access but it’s a waste of time). The guide should instead state that:
Reboot your device into bootloader, via a key combination:
I’m re-locking my FP6 running 3.3-a15-20251210556408-official-FP6.
Reboot your device into bootloader, via a key combination:
With the device powered off
hold Volume Down + Power
In the command prompt, lock critical partition with the following command
fastboot flashing lock_critical
Approve with Volume + then power
In the command prompt lock the device with the following command
fastboot flashing lock
Approve with Volume + then power
I did parts 1 and 2. After fastboot flashing lock_critical, the phone rebooted a couple times but ended up in the “Welcome to /e/OS” screen. Obviously, running step 3 in this state does not make sense. Is this expected, or did the process fail already? What is the correct next step?
If I’m supposed to power the device off and reboot back to bootloader manually, I think the instruction should be updated to reflect this. Would this be correct:
Reboot your device into bootloader, via a key combination:
With the device powered off
hold Volume Down + Power
In the command prompt, lock critical partition with the following command
fastboot flashing lock_critical
Approve with Volume + then power
Let your phone reboot uninterrupted until you end up in “Welcome to /e/OS” screen.
Instead of completing the setup, immediately power off.
hold Volume Down + Power
In the command prompt lock the device with the following command
fastboot flashing lock
Approve with Volume + then power
I think the instructions could be further improved with explanation what to do if the fastboot flashing lock is not run properly. I’m not sure if e.g. completing the OS setup and using the phone for a while before running fastboot flashing lock would be catastrophic.
Make sure to log out of google account before flashing Murena. Otherwise, you get the “FPR Warning” on Murena. In my case logging into google did not help. I had to revert and flash stock Android and log out there. Moving one or two versions forward of the stock Android was not a problem.
Make sure to remove PIN/Password before flashing Murena.
When unlocking and later locking the bootloader, the device reboots. So I put it into bootloader with adb commands
Detailed story:
I have a Fairphone 6 with the official stock Android on it. Security Patch from August 2025 or so.
I checked out the supplied Android and was appalled about the many invasive google spyware. So I gave Murena a go.
Installed e-3.2 (security patch from October 2025). After things looked fine, i locked the boot loader. Then I realized that I didn’t log out out of google and kept the PIN. So I got FRP warnings and couldn’t set a Password. To avoid rollback problems and because stock Android and Murena had different time stamps on the security patches (5. October / 1. October), I played it safe and waited for the release 3.3 (official, not community variant). After a looong download and several restarts of the download, the installation went quite smoothly.
I worked with adb and fastboot on Ubuntu 24:04. I put these tools on the PATH. Adb complained about my user not being in the right group (while it was, I checked, rebooted). The sudo hammer helped: sudo env "PATH=$PATH" <adb/fastboot command>
Thanks for making a really good OS without google.
Good:
Camera works (Fairphone Camera as well as the OpenCamera fork)
AppLounge works quite well. I can install some of my paid apps.
No quirks discovered so far (after 10 days of use)
Criticism
The download speed to get the images is abysmally slow. With Lineage OS on my old phone the download was never so slow.
The AppLounge doesn’t recognize some of my paid apps.
The launcher of Murena is pretty bad, so I switched right away to lawnchair
I quickly tried the “online installer” with chromium browser on Ubuntu. The phone was not discovered so I never tried again.
I don’t really know why the image is twice the size of Lineage OS
I noticed that the bootloader re-locking instruction on Fairphone’s support site has this extra step that /e/ documentation is missing:
Hold the Volume down button immediately as your Fairphone reboots to return to fastboot mode.
However, that instruction is not helpful if you miss the spot and end up booting all the way to the welcome screen. There should be instructions also for that situation since many people will end up there. Also, doesn’t the fastboot flashing lock_critical lead into multiple reboots? How can you be certain you interrupt the correct reboot with the volume down button?
Edit: I ended up following the same steps as I laid out in my previous message as a suggestion for improvement to the documentation. Those worked fine, and I think those should be pretty much foolproof.
You are welcome. I also struggled to find this information. As this guide targets a wide audience (including non-android-developper people), I thought this issue would happens to a lot of people.
Web serial installer ended on a boot loop. Ended up just installing via the terminal which worked first time. 6Ghz networks aren’t showing up for me, but if I remember right you have to do something to get them to work on Android… can’t remember what.
Bootloop here as well when using the web installer. Even tried to manually Factory reset but still looped.
Went with the terminal instead which worked.
Same problem with wifi 6 though, which affects hotspot functionality as well. Came from LineageOS where that was solved
Two major headaches issues that should be addressed in the guide:
An incorrect driver could be loaded when a usb-cable is inserted during bootloader mode;
To solve this, you have to uninstall the android driver in Windows “device manager”, then choose to install it manually, after which you select the “Android Bootloader Interface”. Finally, your device should be detected when running bootloader devices and other commands.
Running flash_FP6_factory.sh will hang, either immediately or after flashing multiple partitions. Mine froze at flashing hyp_b, for example. To solve this, you have to initially boot into fastbootd, by choosing “Recovery Mode” or running adb reboot fastboot. To err on the side of caution, I specifically ran the fastboot.exe in bin-msys\ to execute flash_FP6_factory.sh(In hindsight, it appears to be the latest version). After booting into fastbootd and flashing, the command will hang at wiping misc, which is fine. You can now follow the guide as written. Make sure to flash once more in fastboot mode, as it should run successfully.
I just got my fp6 and unlocked the bootloader without needing the code. Everywhere it says I need the imei an serial numer to get a code and unlock the bootloader, but it never asked me to enter it. This was very confusing because I thought I was doing something wrong. Does someone know why I didn’t need one?
Was your phone brand new? or escaped the sales floor having been unlocked? or possibly refurbished? or possibly a phone returned to the vendor by an earlier buyer?
Using the FP6 for 87 days now, and getting used to it, I want to share a few numbers on the barttery. Like I did with the FP3 here, beneath wanting to have a usable device my goal is to make most of the sustainability of the battery by keeping it around 50% of its capacity and usually charging in slow mode.
So, I am used to load from around 30 to 70% usually (where the charging control in Android 15 is quite convenient), and about every fortnight to 100% to reset the controller.
Thus the average has to become something north of 50% as I avoid to drain it empty.
Recent averages are the following:
running
87
days
usage
1,27
%/hr
30,5
%/day
lasting
3,32
days
charge 1%
05:11
min.
100% every
12,4
days
caring time
02:36
/day
or
10,8 %
daytime
ø battery
54,2
%
Adding the respective battery numbers the runtime/lasting graph became a little more informative:
And I finally managed to get a graph together showing the exact findings on a timeline. The bold blue graph results from the cumulated lasting numbers for the versions:
What I find especially interesting is the oszillating of the daily usage (%/hr), sometimes daily (v3.7.3) or in blocks (v4.0).
It does not correspondend with changes of the using pattern and I have no explanation for it.
