Nice to hear that they managed to fix all of the issues. Does anyone knows when will it be available to install it with Easy Installer?
I’m satisfied with Startmail, not the cheapest though…
Leaving this here as well:
Hi all with the
< waiting for any device > issue in step 6 of “Unlocking the bootloader”: I had the same issue and using another USB cable did not resolve it.
For me the issue was that I had to run the
fastboot commands as root. i.e.
sudo fastboot ... in Linux
→ if you have the same issue in Linux, make sure to make yourself su during the installation, as there are a lot of
fastboot commands and it would be a pain to add
sudo before all of them → enter
sudo su in the terminal before using the first
You can also install android-udev-rules to avoid running
fastboot as root.
More work now, but less work in the future
I just noticed that Fairphone has released a zip file for offline installation, see support article FP4. Install Fairphone OS offline
Seems that installing /e/ other roms is no longer a one way street…
Good thing I didn’t have the time to test my homebrew way back to vanilla, this is much safer
Edit: Worked great, had to use
fastboot flashing unlock_critical (as expected, but not mentioned in the docs).
Why you would add
flash_fp4_factory.sh and just have that call
flash_fp4_factory.command is beyond me Just tell linux users to run
flash_fp4_factory.command, we aren’t stupid…
To understand (and document for others): what exactly does this do?
fastboot flashing unlock_critical will unlock the ability to flash critical partitions like e.g.
abl (contains the bootloader) and possibly others. Since the script provided by Fairphone overwrites
abl, this command is needed.
After unlocking it will erase your userdata, doesn’t matter if you want to flash back to vanilla anyway, but don’t use it just for fun without backups.
This is mentioned in the docs now, so maybe I just didn’t read it carefully enough (or at all) when they released the
OT: Can somebody please do something about the formatting of those support articles. Bold text to signify commands ( fastboot flashing unlock_critical) instead of code blocks (
fastboot flashing unlock_critical) makes it harder to read than it has to be.
And “Enter ” instead of Enter, why, just why
Should you run the “fastboot flashing lock_critical” command again after installation?
If you have arrived at a ROM where you feel at home (since this topic is about /e/ let’s assume it’s that ) and don’t want to flash something new for the foreseeable future, sure, lock it again. That at least keeps you away from partitions that can fundamentally damage your device when messed with (not that disaster can’t be achieved by other means… ).
If your device is working fine and you care about security you might consider relocking the bootloader after that, as the /e/ manual suggests. But beware, if something goes wrong in that process only Fairphone can help you (you’ll have to ship your device to them).
I generally keep everything unlocked, since I know I won’t stop tinkering with my phone anytime soon, but from a security perspective I can’t recommend that!
If you switch back to the stock rom from /e/, Fairphone’s manual lacks this exact command.
Fairphone only writes the command “fastboot flashing lock” under “Locking Bootloader”, but not “fastboot flashing lock_critical”.
That puzzles me.
You are right,
fastboot flashing lock_critical isn’t specifically mentioned in the docs.
I can’t tell you if
fastboot flashing lock implies
lock_critical, meaning if your critical partitions are already unlocked if you unlock your bootloader again, but since
fastboot flashing lock completely removes your ability to flash any partitions I’m not sure it really matters.
Somebody would have to try it, but with the inherent risk of bricking in the process, I won’t be that somebody
I did it as follows and it works without problems.
First of all you should run the script from Fairphone.
Then follow the procedure below:
- Boot your device into bootloader if not already there, and plug it to your computer
- Lock critical partitition with the following command
fastboot flashing lock_critical
- Reboot again your device into bootloader, and plug it to your computer
- Lock the device with the following command
fastboot flashing lock
That doesn’t answer your question if you need to use
fastboot flashing lock_critical or if
fastboot flashing lock is enough.
But since you have a secure working device now, let’s leave it at that
To make the process a little bit safer, I’d suggest not only running the script from Fairphone, but actually making sure the system boots afterwards. If you are in the wrong slot and lock your bootloader you will brick your device!
I have received a reply from Fairphone Support:
Thanks a lot for your patience.
After checking you were indeed right, after using fastboot flashing lock, you must: 1 - Set up the phone 2 - Enable USB debugging once again 3 - Go into fast boot mode and run fastboot flashing lock_critical.
We thank you very much for flagging this to us and we have already advised the relevant team to amend the support article accordinly.
Interesting, so the unlocked state of the critical partitions persists even after the bootloader has been locked.
Wouldn’t it be easier to just use
fastboot flashing lock_critical before locking the bootloader with
fastboot flashing lock?
That would get rid of that whole having to set up USB debugging again…
I have asked myself the same question…
I have also done it so far in the order you have just suggested.
asking support does not automatically means that every answer is correct.
Often, guys from community has more knowledge then the support guys.
I would never trust them blind…
Why?: should that instruction not be adhered to?
I wasn’t talking about those specific instructions per se, my point was about the amount of commands to execute and the possibility of failure when doing it manually.
While there haven’t been a lot of problems flashing those partitions, as I (wrongly) assumed initially, the amount of bricked phones (not only on /e/) when relocking the bootloader, as suggested in those instructions, is still rather concerning.
So maybe people didn’t mess this up a lot, but those who did (mostly without their own fault) are stuck with a bricked device that has to be repaired (reflashed) by Fairphone