I am currently a bit “baffled” and need your help for some clarification.
I was using DivestOS with locked bootloader and was going back to FP OS by using the official guide for “Offline OS Installation”. I unlocked the bootloader again and installed FP OS with the latest patchlevel (2023-05).
Divest OS was using the patchlevel from 2023-06.
I kept using FP-OS for a while and wanted to switch back to Divest OS for enhanced privacy. I installed Divest OS like it was described in the document and also checked for locked bootloaders (which was not the case, because I did not lock the Bootloaders to not trigger the Security Patch mismatch).
So back in Divest OS, I did some checks with:
fastboot oem device-info and I am receiving the following output:
Further check for lockability with get_unlock_ability give me the following output:
(bootloader) get_unlock_ability: 0
OKAY [ 0.000s]
Finished. Total time: 0.001s
From what I am understanding is: if it is Zero, do not be a hero and do not lock the bootloader.
Is there any way I can fix this, or do I just have to wait for FP to release an image with has a similar patchlevel to mine with DivestOS?
I am also not sure, if I can lock the “critical” again, since it is 0.
Yes, you should wait. But still then the recommendation above would be valid here: better not lock the bootloader with OEM unlock disabled.
You might. But it IMHO gives no sense. It probably won’t increase security a lot and as long as OEM unlock is disabled you won’t be able to unlock it again. It will also not make it easier to enable OEM unlock.
Well, actually this is no surprise for me. This value won’t change by itself. Having applied the June Update only means that rollback protection will probably not chime in and brick your device when you lock your bootloader, but it won’t change the .value of OEM unlock ability
Although now the relocking would be more safe, what I wrote above is still valid:
So you might still try the workaround I had mentioned above:
So you didn’t reinstall the system just installed the update, right?
That won’t change the situation, as @Volker already said.
There are two issues at play here, one is the risk of bricking by installing an older release than before (which you are aware of), the other is that OEM unlocking gets reset on first boot, which is intentional (FPOS does it, the CalyxOS devs confirmed that’s what they are doing and I would be surprised if Divest is doing things differently).
My suggestion would be to reinstall the system, don’t boot into Android userland, check get_unlock_ability (which should be 1 at that point), and lock the bootloader.
You can go the Magisk route and set it to 1 but since locking erases userdata anyway there isn’t really a point.
I know the whole get_unlock_ability discussion is a bit confusing, that’s mostly because we were missing a lot of information for a while (and nobody at FP bothered to clear things up )
Yeah, that happens quite frequently (which always increases the risk of unsuspecting people bricking their phones) …
If you don’t want to wait you got 2 options:
Create the current factory images yourself by merging the B.069 ones with the latest OTA update (a bit of a hassle but possible)
Install B.069, update it to the current release and as a safety measure use the Magisk method mentioned above to get your get_unlock_ability back to 1 before locking (the one use the Magisk method still has, probably the route I’d take)
Can you link me to a procedure on how to link the b.069 with latest OTA? I have seen that you have posted an OTA.zip in the latest update release thread. Do I take this OTA file and copy it the contents in the b.069 base and change the .command file to reference to the payload.bin?
How would the magisk path work?
You can use a tool like payload_dumper (sadly the excellent payload-dumper-go still doesn’t support it) and feed it both the factory images and the corresponding OTA update file.
The Magisk route would involve installing the B.069 factory images and updating to the current OTA (or, if you haven’t messed with your phone and are up-to-date, starting where you are) and then it’s basically this …
Thanks for the explanation. I will have a look in the next weeks and see, if I am going that route or just wait for the updated images from FairPhone.
Just received info from support:
I was referred by out department that, technically, Fairphone OS is not supposed to brick because of locking with older security patch. However this hasn’t been tested for the last few updates, so we can’t guarantee it.
If you don’t want to wait for the next update, you can try locking the bootloader and if it does brick, we will cover the costs of the repair exceptionally
The only disadvantage of this is that, if the phone effectively bricks, this entails the fact that you will have to be some time without your Fairphone 4 while it’s getting repaired.
Not quite sure what I should think about that answer, since we all in the forum and me personally once have already experienced a brick like that.
Ladies and Gents,
I report, that the latest update and with the instructions from @hirnsushi (Thank you very very much for your help), I managed to fix the issue and could lock the bootloader. After flashing the FP OS I had to reboot into the Bootloader again and then the unlock ability was 1.