That’s right, a plus point for FP. At least it’s better than having to buy a new one.
Does anyone have experience with what duration you have to count approximately?
Depends, the actual fix of your problem doesn’t take too long, they shipped it back to me within two days of paying. What might take time is that they’ll first send you a quote for a new phone. Then you have to talk to FP support again before they send you a new quote for the actual fix, in my case that took about 5 working days
Maybe now with more cases of this issue and therefore more experience on Cordon side this forth and back might no longer be necessary… 
1 Like
Thank you for the information.
I suppose you can get the phone back with FP OS. Would you repeat the flashing again with this knowledge? I wanted to test the lineage OS after /e/OS and maybe ubuntu os…
The first thing I did after receiving my phone back was in fact unlocking the bootloader and flashing a patched kernel. For now I’ll refrain from locking it again, at least until more of the inner workings are known. Once I’ve got a bit more time on my hands I’ll most likely switch to lineage OS. The first time around I probably was a bit overconfident, coming from a phone that was basically unbrickable, I have tried (mostly by accident). As long as your bootloader is unlocked you should, at least in theory, be safe.
OP reports that they did not manually lock their bootloader, but that the device somehow re-locked itself, which is a bit worrisome and not what should happen at all if one just executes the script provided by FP (speaking from experience and looking at the source). If that is true for you as well I’m kinda lost to be honest.
If that is not the case however, you should be fine doing whatever you want as long as you do not relock the bootloader. If you have no direct need for a different OS and don’t feel comfortable doing this kind of stuff, there is no harm or shame in waiting until the phone is better documented.
Hope that helps 
2 Likes
I think this is a misunderstanding.
The OP said that OEM unlocking was re-disabled during reinstallation of FPOS. This is the setting in developer options allowing you to unlock your device.
The locking itself cannot be completely done by a script (it’s only triggered). You always have to confirm it manually on your phone screen.
As long as OEM unlocking is enabled you’re imho safe. You can always unlock the device again. Only if OEM unlocking is (re-)disabled there’s the risk of bricking the device as if something goes wrong you can’t unlock the bootloader any more.
2 Likes
That’s always true.
The confirmation MUST always done by the user itself.
1 Like
Are you sure? For me this reads like the OP explicitly didn’t disable OEM unlocking
That is the expected outcome, yes.
Flashing the factory image does reset the get_unlock_ability flag that is required for unlocking, it does not lock the bootloader.
But those quotes read like the bootloader was apparently somehow locked without user interaction. I do not know if that is true or not, it seems quite strange and most definitely should not have happened. I suspect there is something more going on…
2 Likes
Interesting, do you have more insights on why this might be happening?
According to the docs that’s not how it’s supposed to work, if I’m understanding it correctly:
Devices should deny the
fastboot flashing unlockcommand unless theget_unlock_abilityis set to1. If set to0, the user needs to boot to the home screen, open the Settings > System > Developer options menu and enable the OEM unlocking option (which sets theget_unlock_abilityto1). After setting, this mode persists across reboots and factory data resets.
I have two FP4s here that had an unlocked bootloader before getting flashed with the factory image and both one(!!!) still report:
foo@bar:~$ fastboot flashing get_unlock_ability
(bootloader) get_unlock_ability: 1
I agree, we are definitely missing some pieces of the puzzle here.
The OP had iode installed before flashing back to stock, others tried /e/, maybe that’s got something to do with it
1 Like
Did you read this?
1 Like
that’s also my understanding…
I did, but for some reason it’s different for one of my devices.
But: I’ve had my confirmation bias goggles on 
(I only checked directly after flashing stock some time ago), only one of my devices actually has the get_unlock_ability flag still set to 1! I’ve edited my initial statement, sorry.
The FP4 that’s only been on stock FPOS (reflashed to stock in the past) still has it, while the one that’s been flashed with CalyxOS (bootloader still unlocked) doesn’t. So, this might actually be related to custom ROMs somehow
I’m very happy now I didn’t lock my bootloader on Calyx…
1 Like
At least FP uncknowledged an issue and has a warning in their instructions and recommends to not lock the bootloader…
3 Likes
This paragraph mentions reboots and factory data resets, but does not mention the expected behavior of the flag in case of a factory image flash and I did not find any information regarding this. I’m not even entirely sure, where the state of the flag is stored.
That is interesting. If you remember my original post, I ended up in the situation I was in because I could not unlock my bootloader after flashing a factory image and locking the bootloader. The alternative is, that locking the bootloader deletes the flag? If you can definitely rule out the first option, this then seems likely.
If that’s the case there is probably something wrong in the process of reflashing the factory image. Ignoring the command to reboot the phone, the last command of the script still accesses partitions, for which an unlocked bootloader is required. This would mean that either erasing the modemst2 partition or rebooting the phone locks the bootloader, seems unlikely…
I just read your updated post. I’m confused…
Me neither, that’s the problem. One of the system / oem partitions probably, can’t be userdata since it should survive a factory reset.
My device running Calyx is in exactly that state, bootloader unlocked but the toogle in developer settings turned off and greyed out with “bootloader already unlocked” written underneath. I didn’t lock the bootloader, so that couldn’t have deleted the flag.
If I’ve reread your posts correctly you only stayed on FPOS the whole time, right?
So the flag reset sometimes happens with custom ROMs and sometimes with the factory images, that doesn’t make it easier to debug… 
Yeah, I know the feeling
on iodéOS, we were not be able to flash and boot in FPOS, after we have installed iodéOS with the correct user-settable avb key (like in calyx and DivestOS) and a re-locked bootlaoder.
FPOS was possible to installed but ended in a bootloop.
Back to iodéOS wthout problems.
And, I never heard anything from one who has installed calyxOS and re-locked bootloader. If he was able to go back to FPOS.
But I heard from a lot of that they returned from /e/OS.
But the big different is that /e/OS and FPOS using the avb testkeys from google.
iode, calyx and Divest not.
Yeah, but in that case a factory image flash should most definitely either delete it or error out.
Basically yes, I was running a patched kernel for some time, but my setup was … weird, not the best example.
Do you remember whether you ever flashed a vbmeta image by other means than the FP script?
Do you happen to know what happens if you erase the avb partition before flashing the FPOS image?
I’m not sure, are they actually flashing every partition? Maybe some oem ones aren’t touched, I haven’t compared the script to the available partitions on device…
The phone that has only been running stock FPOS has seen some 
as well before being reflashed, but it still has get_unlock_ability_ set to 1 after all that
This could have something to do with it, but I’m not sure how the people bricked with /e/ fit into the picture.
I’ve definitely seen someone get a brick with CalyxOS scrolling by in Matrix, did you follow that story? (I didn’t…)