Guide to bootloader and bricking [2025] -- Discussion

Discuss The Forum
, ,
1

Hi there,
I posted a Guide to bootloader and bricking and wanted your thoughts about it.

I wanted to start the discussion with the last section, most notably Psiko’s thoughts, about what we, as a community, and Fairphone, as the company, can do about it.
But I also wanted to let you know some things about the guide itself, including the TO DO list:
To do/complete

  • avb custom keys
  • (virtual?) A/B solutions
  • EDL mode and firehose
  • Fastboot solutions
  • bricking due to full storage

And also where to but the idea that if you’re using bundled zip/scripts from Fairphone (and maybe others, like the automated installers), it already comes with fastboot and adb. The script works out of the box and the process obscures what happens inside. Where to put it in the guide and is that even a good thing?

6 Likes
Can't revert to stock OS
2

As the guide is organised into several posts (which makes sense) and apparently only the first one in the topic was a Wiki post, I made all subsequent posts into Wiki posts now.

Thanks for taking the time to gather and sort all this.

3 Likes
3

You wrote:

This may work on /e/OS. But AFAIK on FPOS the OEM unlocking switch is greyed out while your bootloader is unlocked. So the only way to reset it to “1” is probably to reflash stock OS. AFAIK get_unlock_ability will be 1 before booting into the system.

4 Likes
4

So you mean

  1. flash FPOS → do not lock → reboot to FPOS

Will leave you with :
a) an unlocked bootloader
b) a 0 unlock ability
c) no OEM unlocking in dev settings

And the solution to that is to re-flash thus :

  1. flash FPOS → lock bootloader (critical/lock) → boot into FPOS

The state would then be
a) bootloader locked
b) 0 at unlock ability
c) OEM unlocking is available.

Do I summarize it correctly?

1 Like
5

Yes, exactly. This is what I’d expect. Still it should be confirmed to be true on all devices.

And - just a matter of precaution:
2. flash FPOS → check if unlock ability is really “1”; if yes: → lock bootloader (critical/lock) → boot into FPOS
(and btw.: I don’t think that relocking critical is necessary - but that’s another discussion anyway)

1 Like
6

Hey there, thank you for taking the time and effort to summarize all this information.

I currently have CalyxOS installed and everything is unlocked + OEM switching is greyed out. I want to switch to iodeOS (because of the CalyxOS hiatus) and re-lock the bootloader (hopefully this will allow some banking apps to run).

I want to read up more on how to re-flash my device without bricking and maybe learn something on the way, my questions currently are:

* Do we know how/why flashing FPOS re-enables the OEM unlocking switch?

* Are there other *OS images that will do the same (re-enable OEM unlocking switch)?

* If get_unlock_ability is ‘1’ can i be sure that locking will *not* brick my phone?
The official Fairphone guide about ‘Re-lock the bootloader’ (https://support.fairphone.com/hc/en-us/articles/10492476238865-How-to-unlock-and-re-lock-the-bootloader) does not even mention the ‘get_unlock_ability’ command, this seems careless to me or am i missing something?

7

Normal because of this

Noone can or would give you this guarantee, however the chance to brick is rather low

8

Hi, thanks for your interest and your reading.
As far as I know, it would not be safe re-locking on iodéOS because it’s not an official OS.
You would have to do some custom AVB keys magick to make it happen.
I have way less time now with work, but I still intend to give an outline on what to do for each OS. Eventually.

In the meantime, know that you can re-lock on Android OS and on official /e/ builds.

I think it’s about the first boot of FPOS that, if done before re-locking, leaves you in an dangerous situation. I guess that it’s because of a easily skipped step on a long and confusing process.

9

I dont get that point. You can lock the bootloader when you install IodeOS normally, so why should it be different here? You can lock the bootloader with Iode, Calyx, e/OS, they all support this, only Lineage does not.

1 Like
10

I’m not familiar with the install process. If it is a script or an automated process, then maybe the custom avb business occurs under the hood and you’re not aware of it.
But if you do it manually typing each command you might have to do it. If the install tutorial warrants it, you can’t skip it.

11

All those custom ROM have some kind of installer/script and no manual flashing step by step is needed, thus no issues to lock the bootloader in general except for LOS who in general do not support it.

12

I wouldn’t say that. There may be scripts that do not re-lock the bootloader. Until we inspect it, there is no way to know.
It’s also important to be aware of what the script does, as a matter of open source ethos and autonomy in our practices. Also to know what happened and how to fix, in case something goes wrong.

13

Its documented good enough that you can relock the bootloader of the mentioned custom ROM in general and that there is no need to do

Yes things can always go wrong, however one can in general lock the bootloader with all those custom ROM without needing magic or any special manual tweaks.

14

Well, whether you’re aware of it or not, the install script can do avb custom keys replacement, so i’m just going to document myself about it and draw some general patterns, report back. But, the header is still : if, for whatever reason, avb keys partition isn’t flashed, you can only relock on stock or official /e/

15

Hi, just checked the iodéOS docs. Apparently bootlocking is supported.
Probably via custom AVB key.
I got lost a bit during browsing their source code, and I’m not eager to download a 1.5GB installation zip file with my current data plan. So make sure to either use the automated installer or follow the manual tutorials closely.

16

As I said already before

17

let’s be as specific and accurate as we possibly can, please. This is how mistakes happen.

  • for e/OS/ it’s only possible for official builds. As far as I know, you can’t lock the bootloader on community builds.

    image
    image949×287 8.89 KB

  • CalyxOS project is on pause and I think don’t really let you install it.

  • iodéOS uses an automated script that purports to relock the bootloader

  • I don’t think relocking is possible for Ubuntu Touch

  • I don’t think relocking is possible for SailfishOS (i don’t know if there’s even a bootloader with sailfishOS)

  • Relocking is not possible on LineageOS (as mentionned)

1 Like
18

Thanks for all your suggestions and for mentioning AVB (Android Verified Boot),
see here: Android Verified Boot 2.0.
I read up on it and now learned this:

vbmeta

There is a parition called “vbmeta” (seems the FP5 additionally uses “vbmeta_system”) containing hashes for partitions used to boot Android. The bootloader of your phone will verify the partitions against these hashes and if they match the boot is “verified”, meaning the system is considered coming from a trusted source.

If your phone is LOCKED then the boot process will halt if it is not verified.
If your phone is UNLOCKED then the boot process will continue either way.

I downloaded the FairphoneOS and the /e/OS images and both flash the “vbmeta” and “vbmeta_system” partitions.

avb_custom_key

There is another feature described in the AVB documentation linked above:

“[..] the boot loader supports a virtual partition with the name avb_custom_key. Flashing and erasing this partition only works in the UNLOCKED state. [..]
When the custom key is set and the device is in the LOCKED state it will boot images signed with both the built-in key as well as the custom key. All other security features (including rollback-protection) are in effect, e.g. the only difference is the root of trust to use.
When booting an image signed with a custom key, a yellow screen will be shown as part of the boot process to remind the user that the custom key is in use.”

The iodéOS image flashes the “avb_custom_key” partition (excerpt from their flash script):

  $fastboot erase avb_custom_key
  $fastboot flash avb_custom_key avb_custom_key-FP5.bin
  $fastboot flash [..] (flashes a whole lot of paritions here)
  $fastboot reboot-bootloader
  sleep 5
  $fastboot flashing lock

LineageOS does not seem to flash “vbmeta” or “avb_custom_key” so locking the phone will not find a valid hash for the system and other partitions and fail to boot if LOCKED.

Seems to me any OS writing either a valid “vbmeta*” parition or “avb_custom_key” can be locked and if the hashes are correct it will boot.

But, the header is still : if, for whatever reason, avb keys partition isn’t flashed, you can only relock on stock or official /e/

My take is this is not always true. If for whatever reason the “vbmeta” and “vbmeta_system” partition are not flashed correctly or contain invalid data you can not boot FairphoneOS or /e/OS when LOCKED.

And of course there is still ARB (Anti-Rollback-Protection) to consider and i do not fully understand how A/B partitions come into play here.

My current plan for moving from CalyxOS to iodéOS is this:

  • Flash FairphoneOS, but keeeping everything UNLOCKED
  • Flash iodéOS and then LOCK
  • Before flashing make sure the images use the same or a newer security patch level than the image flashed before to avoid running into ARB (Anti-Rollback-Protection).

Flashing FairphoneOS does not seem to be neccessary according to others in the forum, but my hope is since it flashes A and B partitions and iodéOS seems to only flash one partition, if something goes wrong for one OS i can still boot the other.

What do you think?

19

Thanks for the writeup! I could probably use part of this for the guide, if that’s okay.

Yeah so, now you’re talking about partition integrity. My point was, you can only lock bootloader on stock and on /e/OS official if vbmeta is untouched but healthy. Of course, if vbmeta is corrupted, it’s another question.

Regarding your plan, I would indeed advise for flashing stock Android between two ROMs. You know to check the SPL for that.
Concerning the A/B system, i’m surprised that iodéOS only flashes one partition. That means that OTAs are not seamless? You saw the flashing script, are there not a loop for current_slot and inactive_slot?

20

it is seamless…

I get the impression the whole discussion is just making things way too complicated, just flash, and check get_unlock ability is 1 before locking… and just for reference I also dont think flashing FPOS inbetween is needed