A while ago I purchased a FP6 from Fairphone. I just tried installing /e/os using the web installer. I followed every step successfully, but the end result is worrisome.
After boot-looping several times and showing the Murena logo and a message telling me that any unlocked device is potentially unsafe, the phone ended up in the bootloader screen. Any interaction inevitably brings back that screen. The web installer tells me the install is complete, and that the “e” logo should pop up but I’m pretty much stuck.
Security version is compatible, install PC runs on Linux, no problems at any point in the process are to report.
I apologize for using the web install, looks like it’s frowned upon here /s
I would be happy to share any necessary info (sorry I’m not a pro lol)
Update: I managed to install it using the command line method, just had a couple questions about locking the bootloader.
What are the effects of doing it? Is it very recommended for someone that mostly uses open source/highly recommended apps only? (ie gmail etc)
I installed the what I think is the latest A15 official build (IMG-e-3.3-a15-20251210556408-official-FP6), am I correct in assuming that 20251210 means dec. 10th, and thus relocking my bootloader should I do it will not send me to kingdom come?
I had the problem rather that I suddenly had no connection to the mobile phone with Linux after deleting although USB debugging was activated and unlocked, I then had to install via console and that ran smoothly, should probably be more secure.
Just to be quite sure, I’m a little paranoid now lol.
If I remember correctly the default android security version is from around November 21st, and the security patch from /e/is marked as Dec. 1st. Is there a way to be entirely sure? I spent too long on the install and now I’m not sure lmao.
Also, the android security update is from dec. 1st but there’s also a Vendor security patch level from aug. 5th, which does not exist on my old phone (not running /e/), is there something to be concerned about with it?
You can wait but the problem is that you will loose all your data once you relock in a few weeks / months as relocking will erase everything again.
So the best is to install and relock the soonest IF possible: as Piero said, if you cannot check the original Android Safety Patch Level because it was replaced by the one of the new (unlocked system), then send the two following commands in fastboot mode to check the state of your device:
check bootloader status by running :
./fastboot oem device-info
./fastboot flashing get_unlock_ability
if the return is 0 DON’T TRY TO RELOCK
risk is to brick your device (wait untill next /e/OS update)
Also an important improvement is that there should not be anymore a confusing 4-5 days difference between the original Android SPL date from fairephone and /e/OS SPL date, so the command line instructions stating that the /e/OS date must be same or more recent should now be correct in all cases.
We just miss now an auto-check of those dates or of the get_unlock_ability variable status by Web/easy-installer so that to end getting people stuck at relocking without a clue
Its progressing !
All right, looks like I was right to worry a bit, the unlock ability is 0. I’ll wait a couple days/weeks and redo the test, I can still use my old phone for a while, so I’m not worried about losing any data.
Somehow this question has invited … a “what next” reply. You might have asked “Alternatively, go back to FairphoneOS?” There is not an alternative to finding best information before you decide what to do.
You still have your first problem of making a well informed guess of your Android SPL at point of unlock.
get_unlock_ability does not query the indexed date on the phone. It does not tell you that dates inform ability to lock it tells you about device state … is it ok to unlock? No in your case it is not ok to send unlock commands.
When you decide that there is no chance that you will roll back; you could then run that enquiry to check device state. You may get a 0 again, then you will be asking a question like this Week 52, 2025: Development and Testing Updates - #10 by Helight, please follow the answer and reply he gives a nice description of what he did.
My earlier advice is quite simple
I think best you can do is look at Fairpone available downloads and make a guess of the last build you had installed.
Here is the check from that source as a screenshot
I am fully decided about what to do, I was just wondering whether waiting for an update or two constituted an insurance that I would not brick my phone when I locked the bootloader with /e/OS loaded. So for me FairphoneOS is out of the picture.
In short, my question is “is waiting for the January/February security version on /e/OS patch a sure way to not brick it when relocking the bootloader, as that would make sure that the security version of fairphoneOS when I first flashed /e/ is inferior to /e/’s current (Jan/Feb) security version?”.
You are unlikely now to move back from get_unlock_ability=0 so you can anticipate go back to FairphoneOS very briefly proceeding like Week 52, 2025: Development and Testing Updates - #24 by Helight. Locking the Bootloader at that time will ofc Format data.
Ok, no worries. Just out of curiosity, what does “Reinstall stock OS over CLI” refer to?
Also, is briefly rolling back to stock OS strictly necessary or can I just run fastboot flashing lock_critical and fastboot flashing lock when the jan/feb security update comes out? I must admit I’m not sure why rolling back to stock was necessary in the case you linked.
Also also, I take it that the FP6 fairphoneOS downloads are totally up to date, or is there potentially a bit of a margin? I was quite sure that my fpOS security update was from November, but that 1% of doubt makes me nervous. That’s basically the extent of my issue regarding locking the bootloader.
Could you define what a device state not being optimal for locking is and whether I might be able to just run the commands as described in my previous message when the conditions (jan/feb /e/os security update) are met to lock the bootloader without issues (similarly to what GabrielT mentionned above)?
Also, the current /e/ security version on my FP is the 1st of December, so from what I understand I shouldn’t have any issues, seeing as the latest security patch of FairphoneOS is from the 5th of November. As stated in the guide “Before installing, always verify that the /e/OS rollback date (the 5th of its SPL month) is greater than or equal to your device’s current Security Patch Level.”, so unless I somehow had a (afaik non-existent) newer version of FairphoneOS with a security patch above Dec. 1st, I should be good to simply lock, surely?
I suppose I simply don’t understand the ramifications of get_unlock_ability for relocking the phone.
There is also a “vendor security patch level” from the 5th of August on my /e/ but I have no idea what it is.
Sorry if I’m starting to get annoying, I’m a bit out of my depth and don’t want to risk an expensive device.
No need to apologise. I started to write Eos Web Installer Support improvements when I read of people launching into flashing their brand new phones as if it was dead easy and needs zero preparatory understanding.
Now you are oversaturated with information. I recommend to sleep on it. I find myself repeating myself but I do understand that the links I have given you are not dead easy reading.
Good that you have come to this conclusion regarding dates on your own.
However get_unlock_ability=0 tells us something other than the proper install instruction has happened (yes, of course, eosinstaller installer did something and you recovered the phone). No harm done … except
User experience tells us that if you install and lock in one flow then one will see get_unlock_ability=1 – what is the difference, does it matter? You would like “define”. [1]
I completely empathise with your predicament, but I would only aim to try to point you towards “minimum risk reading material”.
Is something different and of no concern today.
[1] Locking has to ensure full device integrity. Say that integrity cannot be confirmed one might expect locking to fail with error. It is however complicated by lock being a two stage command.
Yeah, I’ll probably sit on it for a little bit, just trying to figure out a clear path forward. Looks like the “Helight process” is gonna be it, but I was rather hoping not to have to reinstall fairphoneOS and just be able to “wait it out” with a security update from /e/ in the coming months (still not entirely sure whether that would work lmao).
My issue with the reading material is that most of the time explanations somewhat cut corners or do certain things for reasons I don’t understand (i.e. not letting the OS boot) because they are written by and for people that know their way around this stuff, so I’m trying to get a clear picture of what I’ve got to do and not blindly paste random commands into a terminal and end up with a wonderfully useless little rectangle.
Thanks for bearing with me thus far, just trying to entirely eliminate any doubts (at the expense of having you repeat yourself )
