I tried out iodéOS 3.2 on my FP4 today just to find out that audio and video recording qualities are awful. My issues sound exactly like the ones described here. So I wanted to see if the issues on Signal are related to iodéOS first by reverting back to Fairphone OS.
As part of the setup instructions for iodéOS, I flashed the avb_custom_key provided on their GitHub. All went well, I was able to lock the bootloader too.
Now that I’m back on Fairphone OS, I figured I should relock the bootloader again but I then remembered part of the iodéOS setup instruction mentioning that if I get “get_unlock_ability: 0” and try to lock my bootloader that I will brick my phone. Turns out I do get 0.
I did follow the FP OS installation instructions but couldn’t find any mention of the avb_custom_key. Am I correct in thinking that I need to flash the original FP4 avb_custom_key before I can lock the bootloader again? If that’s correct, where would I get this file?
That’s a firmware / driver issue, your experience will most likely not be much different on stock FPOS.
The stock keys are built in, there’s no keyfile you could flash.
Try clearing the custom root of trust fastboot erase avb_custom_key and reinstalling stock FPOS. Not sure if that’s necessary, but the stock install script at least doesn’t clear it, so it’s worth a try.
Oh and could you check the version of FPOS you have installed (Settings → About phone), up until very recently, if you downloaded the A.170 release, you would have gotten the A.163 version instead, because of a wrong URL.
I ran fastboot erase avb_custom_key and then reinstalled FPOS.
I then reenabled USB debugging and entered fastboot. fastboot flashing get_unlock_ability still returns get_unlock_ability: 0 however.
I checked the version and it was an A.170 release.
Could you check the state of get_unlock_ability before booting the phone
Not completely sure, but that reset might be caused by the frp partition on first boot. IIRC correctly iodé doesn’t flash that one.
Oh and since iodé warns against unlocking the critical partitions in their instructions
Unlock your phone by following the instructions from Fairphone website, but do not unlock critical partitions (do not execute ‘fastboot flashing unlock_critical’).
Did you unlock the critical partitions before flashing stock?
I honestly know very little about all of this stuff, so I’m not sure what you mean by an frp partition but I can see that it says 1 immediately after installation.
Would it be safe to lock_critical and lock at this point?
Did you unlock the critical partitions before flashing stock?
I did before flashing FPOS. I did not before flashing iodé.
Safe, no, I never recommend locking the bootloader, because there’s always a risk involved.
You seem to be on the right version, but ultimately you’ll have to decide if you want to risk it.
There’s really no need to lock the critical partitions, but in the spirit of following the official instructions, you can of course do it. If you do, check get_unlock_ability before you lock the bootloader completely.
I was on CalyxOS but I have problems with touch-input issues when the phone is lying and some phoen mic issues. My plan is to check that with Stock rom and send it then to FP.
What I did:
and because my CalyxOS was working with a locked bootloader I need to do this:
The only thing that did not worked as I expected was this line:
I was assuming that this “Command failed” was okay in this case, so I followed the official faq article and run the “./flash_fp4_factory.sh” from the extracted latest fp4 factory zip.
The installer script runs fine and stock-os is able to boot but I am now with an unlocked bootloader.
So I read the yellow warning here:
It says in warning 4/4:
If you install an OS with an older security patch level than your previous OS, Android's roll-back protection might brick your device when locking the bootloader! Wait until you get a software update with the same or newer security patch level before locking the bootloader.
I am now unsure if should do that? I think I run the latest CalyxOS stable before. I rememder that I need to send my FP4 once to support because of nasty bootloader-bug when I try to lock the bootloader once with a rom.
This is my result from the get_unlock_ability check:
If all you are trying to do is check the functionality and then send it to Cordon no need to lock the bootloader IMO, they’ll probably reflash the phone as a matter of policy.
But let’s get into it anyway
Calyx only locks the bootloader and doesn’t lock the critical partitions beforehand (because you can’t touch those with a locked bootloader anyway), so those being already unlocked is perfectly fine as you suspected.
There is your first problem, you don’t want to boot into the OS before locking because the first boot resets get_unlock_ability.
Open the flash_fp4_factory.command file in the folder where you extracted the Fairphone factory images and change line 23 to REBOOT_TO_BOOTLOADER="true"
Get the new SHA256SUM for the script (sha256sum flash_fp4_factory.command if you are on Linux) and replace the one in the SHA256SUM file with it (last line)
Run the installation again and check fastboot flashing get_unlock_ability afterwards
(Yeah I have no idea either why the official script boots you into the system and the docs instruct you to lock it afterwards, which makes it waaay more unsafe
I mean just make locking the bootloader part of the script and automatically check get_unlock_ability beforehand, like Calyx does, that would have saved so many devices from needlessly having to be sent to Cordon. But I’ve honestly given up at this point, this stuff isn’t going to change.)
No, you don’t, CalyxOS follows Fairphones SPL (you can see the updates here), so as long as you install the latest FPOS release ( FP4.TP2D.C.0112 in this case), or update your system to that state if current factory releases aren’t available, you should never end up with a security patch level that makes it impossible to lock your bootloader.
TL;DR: I wouldn’t lock it just for a check, but if you want to don’t boot into it and always check get_unlock_ability.
