Welcome to the community
I’ve moved your post to this topic, since you seem to want to install /e/, not iodé.
Short answer: Yes, if you lock the bootloader you can absolutely brick your device.
Slightly longer answer: If get_unlock_ability was reset to 0 on your phone (so OEM unlocking got disabled during installation), you didn’t enable it again and something goes wrong when locking the bootloader, like for example you installed an older ROM than the one you had installed before, triggering Anti Rollback Protection in the process, yes.
If you lock the bootloader you lose the ability to do that.
What’s the message about? Stock FPOS version you had installed too new and no matching /e/ release available?
thanks for moving, I try my best to participate in the right threads.
I wanted to install but I also stuck reading at iodé which also sound pretty nice to me.
So I also considered to check that out, too; but my story started with /e/os…
My version is (I guess the latest):
FP4.F_P4D.A.163.20220826 (updated a few days ago, tight after I received it)…
You think it could be a version incompatibility with that one to install?
If I install a new one I don’t care what I have on it, because I delete that anyway, right?
but what was first? The Chicken or the egg?
Sorry, but I didn’t understand at all, maybe because of missing know how and why anti rollback protection can kick me.
Imho I should be able to install old or new OS as I wish. So I can do on my Computer.
Am I not able to install a stock ROM, like a reset, which also install FP stock rom, locks the boot loader, etc. like it was shipped?
I just can compare the ability on Samsung Devices with Odin or whatever was used for.
Everything was recovered, partitions, Boot loader, Recovery System, the flashing counter was reset, even the providers Logo appeared and everything was back to the state when you receive a new phone. By any mistake you were able to restart the rooting or flashing process.
However, maybe I should learn now: “never Lock the Bootloader” thanx.
But to understand this, you say that this OEM process is locking the boot loader and I have to unlock it before proceeding?
Maybe that’s a stupid question, but: If I recover my System with OEM Software, as I described… everything is back to normal. So I will have a functioning running OS with locked boot loader.
What’s wrong with that?
Why is that bricking the device?
At the moment I can’t lock the boot loader anymore (option is grayed out) - so I’m save.
Changing the slot manually is only available on an unlocked bootloader. The slots aren’t meant for you try different OS, they provide a (automatic) fallback after an OTA update. If your bootloader is locked and you are in the wrong slot, you’ll have to unlock it again to change it, if you can’t unlock it, your phone is bricked.
Anti Rollback Protection is meant to prevent malicious actors from installing previous versions of an OS that might contain known vulnerabilities, that could be exploited to gain access to your data.
Once you are at a certain patch level, installing a previous version and locking the bootloader will trigger it, rendering the phone unbootable and potentially bricking it.
Yes and no, you can go back to stock, but you won’t be able to go back to the state you where in when you took your phone out of it’s packaging (if you performed an OTA update at some point).
Well, if you want the flexibility you mentioned above, yeah, don’t
There is a bug in the FP4’s bootloader that can reset OEM unlocking when flashing a ROM. OEM unlocking is a separate switch you have to toggle in the Developer Settings, that needs to be set to ON for you to be able to use fastboot flashing unlock.
If that happens and something goes wrong when locking the bootloader, you can’t unlock it again.
At that point you own a fancy
That’s the OEM unlocking switch and it doesn’t lock or unlock your bootloader, it changes your ability to do so. While your bootloader is unlocked that switch is greyed out (at least on stock FPOS).
Is the switch set to ON? What’s the output of fastboot flashing get_unlock_ability?
As long as you don’t lock your bootloader you’ll always be able to switch between slots. Doesn’t mean you should though, you generally only need that if the OS you just installed doesn’t boot. But, most install instructions should have put you in the right slot already.
Better forget about the ability to change slots, it’s not meant to be used manually, the OS / OTA updates will manage your slot.
If you don’t lock your bootloader, no.
If you plan to, don’t install anything older than 1.4.0, check get_unlock_ability and before locking it double-check the patch level under Settings → About phone → Android version.
I generally would still advise against it, if you don’t need the added security features of a locked bootloader. There’s always a risk involved and personally I’d rather be able to fix any issues myself instead of having to deal with support / Cordon, ain’t nobody got time for that…
I would like to underline @hirnsushi 's point again, as I also had such an “accident”
Reset the phone to factory settings (if necessary), compare the security patches of the new OS, if there is “the slightest doubt” do not install and wait for an update/security patch of the new/other OS.
Wooow… I have read that now multiple times. Is it really that bad?
…please, excuse me for writing such confusing stuff. Of course you’re right; it’s just the ability given.
So if greyed out, it’s unlocked, like the output of your following command confirms:
first booting to bootloader and running: fastboot flashing get_unlock_ability
Meanwhile I played around with preinstalled stock FPOS.
I locked and unlocked the bootloader and now I feel a bit more safe; thanks to y’all.
I will keep it unlocked now
I updated a few days to: FP4.FP4D.A.163.20220826
So I assume Version FP4D.A.163; Patch level date 20220826
I also found that command in your other post with CalyxOS to show version with adb-command:
first booting to FPOS and running: adb shell getprop ro.build.version.security_patch
The 1.4.0 Version seems to be from 202209 (September), so its newer like FPOS, but the easy installer keeps saying that its still not installable yet.
Maybe the easy-installer has to be updated?
I swaer that I’ve seen a link to the manual installation of /e/os, you posted? I don’t find it yet anymore, but I found this… https://doc.e.foundation/easy-installer
…and there is no Fairphone 4 listed in the compatibility overview for /e/os.
That’s maybe why the title of this thread contains “(beta)”
Well, FP support is constantly overwhelmed and takes some time to respond, Cordon (at the beginning) often declared bricked phones as unfixable and had to be convinced they were actually repairable.
The process has been improved I imagine, but we are still talking potentially some weeks till you get your phone back.
Nope, on stock FPOS, if it’s greyed out your bootloader is unlocked, on /e/ OS it’s not greyed out even if your bootloader is unlocked, the important part is if it’s set to ON.
That command doesn’t tell you if your bootloader is locked / unlocked, it tells you if you have the ability to lock / unlock the bootloader (so essentially the state of the OEM unlocking switch mentioned above), which you absolutely should check before locking the bootloader.
Oooff, you shouldn’t play with that, especially since you switched slots as well, and definitely don’t feel safe, people have bricked their phones from less. Let’s just say you wouldn’t be the first…
I mean you technically checked get_unlock_ability before and it returned 1, but my nerves, uff, I’ve seen too many
The important part isn’t when it was released, but, as mentioned in the linked merge request, they actually pulled in the newest proprietary stock FPOS bits. Outdated releases often get published even after Fairphone releases new versions, since it takes some time until those updates get picked up.
As mentioned before, the FP4 isn’t compatible with the Easy Installer yet, you’ll have to follow the:
That’s the easiest way at first to close tickets … but yeah… that makes it more complicated to convince the support as a customer…
at least it looked good on the screenshot… I will keep the switch position in mind (if I manage to install /e/OS.
I read that link from @yvmuell and you https://doc.e.foundation/devices/FP4 and as I find I should skip the last part, because they are writing about locking the boot loader - what I better should leave as unlocked…
And they also make a mention about lock_critical…
…but after our conversation I guess I just should skip that part, right?
In my case the command failed after I did fastboot flash unlock fastboot flash unlock_critical
it feels as if it is the same command like without the word ‘critical’.
And that brings me to my next question, if I look to the manual installation.
They show 44
fastboot flash foo_a *.img and
fastboot flash foo_b *.img commands.
Ok, got that so far.
My thoughts now are:
As I said my default slot is B.
Do you think it would be a good idea to chose only the A-commands, because the last command is fastboot --set-active=a
and could keep my “default-B-slot” or am I misunderstanding something at this point?
In this case I have to change the slot because the Howto says to do so.
Is it right, that I can have two operating Systems installed side-by-side?
Or do you recommend to execute all commands like they are shown?
And unlike a Screenshot, which I can’t find right now, secure boot is set to yes.
Is that a problem?
Should I change it to no?
fastboot flashing unlock unlocks your bootloader fastboot flashing unlock_critical unlocks the critical partitions, so you can flash those (which you’ll need)
Don’t mess with the install instructions, the slots aren’t meant to be used by you. OTA updates just alternate between the slots and they expect certain content to be there. A / B slots are there as a fallback if an update fails.
You start in slot a, the next update is installed to b from a running system, after a reboot the system switches to b, but if something goes wrong will fallback to a.
You can’t install two operating systems at the same time (not for long anyway), just ignore the slots, they aren’t really useful apart from their intended purpose.
I mean you can try a lot of stuff if you don’t lock the bootloader (or decide to repartition the phone), but I’m assuming your goal is to have a usable system in the end
O M F G
what can I say?
I did it after reading the repartition-Link.
And it worked a 100% like a charm (or how do I say it correctly?).
Why are you @hirnsushi not an Fairphone-Angel?
In the end you also helped @bookworm, too in repartitioning.
Anyway, the outputs (just for the protocol), Success:
But first I set the path variable to my adb-platform-folder, so that I didn’t have to replace the path to IMG-Files and I was able to copy/paste the commands from the Howto.
I started by booting into the bootloader and rebooted into it again, just to make sure, that the commands are working with the new path entry.
the Internet connects us all on the small planet; City hin oder her
and answering a forums post so fast is kinda the same like answering an e-Mail, but everyone can participate on the experience. Isn’t that what makes a good community?; sharing know-how, errors and success?!?
Sure, I’ll take a look, it’s perfectly set to 1.
Also within bootloader, written down in red says: DEVICE STATE - unlocked.
But as we said I skipped the last part from /e/os manual, locking the bootloader.
And also, like you said it’s true. The OEM-Switch mentioned above is not grayed out in /e/os.
So this could cause a problem. Maybe that should be grayed out from any running OS, if bootloader is unlocked, just for security reason.
I am not familiar with Google’s security patch schedule, but it seems there are two every month: at the first day, and at the fifth day. Is this something I need distinguish in this regard?
I am pretty much assume, that /e/OS in fact includes the security patches up to August 5th. But I still do feel uncomfortable since it is not mentioned explicitly.
To my understanding, there is never an issue as long as the bootloader is not relocked by myself. I want to know that nevertheless.
Just to be sure: Is it possible to brick the phone while locking the bootloader, even if you ensure everytime that the OEM unlock capability is activated (i.e. fastboot flashing get_unlock_ability returns 1)?
As long as this is active, it is always possible to execute fastboot flashing unlock[_critical], isn’t it?
It seems there is no way to check if anti-rollback protection would kick-in in advance to locking the bootloader. It sound like this would be super useful.
The interesting information isn’t in the /e/ release notes, but in the commit history of the FP4 specific repo. If you have a look at the bottom of this merge request, you can see, that A.163 has been released in 1.4, while A.170 is planned for 1.5.
The important part is, does your phone match the firmware patch level, which seems to be the case
Since Fairphone has never actually told us anything about the specifics of the bootloader bug, I’d say, there’s always a possibility. But you are probably asking the wrong person, past experiences on this forum have made me a bit overly cautious. (And I’m running Magisk, so I can’t lock it anyway )
Generally you should be fine, others have been able to just unlock their bootloader after a failed attempt, but I can’t guarantee it.