[Solved] Problem to unlock device via fastboot on FP4

Never let go of this cable xD

1 Like

what are you trying to do, if i may ask?

Probably that :smirk:

oha…didn’t see that. thx…

Well understood
:+1:

If I’m not mistaken you should also run fastboot flashing unlock_critical
Otherwise you might have problems later on. Maybe someone else is able to clarify that.

1 Like

Thanks a lot!
but I see this because :

$ fastboot flash bluetooth_a bluetooth.img
target reported max download size of 805306368 bytes
sending 'bluetooth_a' (940 KB)...
OKAY [  0.042s]
writing 'bluetooth_a'...
OKAY [  0.005s]
finished. total time: 0.047s

[…]

$fastboot flash modem_b modem.img
target reported max download size of 805306368 bytes
sending 'modem_b' (149612 KB)...
OKAY [  4.021s]
writing 'modem_b'...
OKAY [  0.332s]
finished. total time: 4.353s

but :

$fastboot flash xbl_a xbl.img
target reported max download size of 805306368 bytes
sending 'xbl_a' (3298 KB)...
OKAY [  0.109s]
writing 'xbl_a'...
FAILED (remote: Flashing is not allowed for Critical Partitions
)
finished. total time: 0.122s

I’ll try again later
(The lawn has grown and I have to mow before the rain! :innocent:)

yes, that seems that /e/OS is writing propritary fimware blobs.
Means, critical_partitions must be unlocked first
fastboot flashing unlock_critical
and can be later locked again at the end.
fastboot flashing lock
fastboot flashing lock_critical
But it is not absolutly mandatory, normally, they get locked automatically during next OTA update.

1 Like

Thank you all!

I followed the documentation on :
https://doc.e.foundation/devices/FP4/install

Just Work !

2 Likes

No, I don’t think that this is true.

OK, thanks, Then not for /e/
Some other custom ROMS are doing that in their OTAs, if needed :wink:

I still doubt that this is possible without the user’s interaction. Apart from that, why should an OTA update do that as some users don’t want to have the device locked? :thinking:

1 Like

Volker, locking critical_partions is different to lock the bootloader.
That are completly two diffent things.

for example
if a ROM doing an OTA update, the bootloader has not be unlocked. that’s clear.
but, if this update have to write new firmware blobs, it must be written in critcial partitions, that are normally locked because of data integrity.
it is then possible to open this partions, write firmware blobs, and close it again.

As said, nothing to do with locked or unlocked bootloader and OEM unlocking option.

Don’t think it’s working this way. I think OTA is able to write partitions even if locking_critical is enabled. It doesn’t “disable” and “re-enable” this function during the process. So I think

is still not true as after an OTA update also locking_critical remains off (and is not automatically re-enabled) if it was off before.

2 Likes

I agree, none of the OTA updates lock / unlock critical partitions.

Calyx for example uses the OTA update mechanism in fastbootd (fastboot in userspace) to flash some of the partitions during installation, critical partitions are still unlocked on my phone.
And the recent Fairphone OTA didn’t lock critical partitions on the other device I have access to either.

So for @Volker locked stays locked and for me unlocked stays unlocked, I’d say case closed :smirk:


Edit: I just stumbled upon this bit of information in the Android docs:

OTAs should fail to update critical sections if the device is in lock critical state.

So this…

…might actually not be the case? :thinking:

2 Likes

The bootloader of my device is unlocked, but critical partitions aren’t. So I can tell you after next OTA if it works…

1 Like

Maybe this depends on the OTA as well, I’m not even sure OTA updates generally should touch critical partitions?
According to the docs:

devices shouldn’t ship in the unlock critical state

So if critical partitions are locked from the factory and OTA updates shouldn’t update them, are they even supposed to be changed apart from flashing factory images?

Would be nice to know which of the partitions are critical partitions, the normal system partitions mentioned in the docs probably aren’t and the part about critical partitions doesn’t offer much more information :thinking:
Probably anything that’s loaded before the system is booted. If we use this (old) blog post as a reference, that would mean abl, xbl & Co.

xbl_config_a
devcfg_a
xbl_a
tz_a
hyp_a
keymaster_a
abl_a
aop_a
imagefv_a
multiimgoem_a
qupfw_a
uefisecapp_a

and the same on slot b obviously.

2 Likes

I’ve just done an OTA update and as expected it worked perfectly (with critical partitions locked). :slight_smile:

1 Like

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.