Never let go of this cable xD
what are you trying to do, if i may ask?
Probably that
oha…didn’t see that. thx…
Well understood
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.
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! )
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.
Thank you all!
I followed the documentation on :
https://doc.e.foundation/devices/FP4/install
Just Work !
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
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?
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.
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
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?
The bootloader of my device is unlocked, but critical partitions aren’t. So I can tell you after next OTA if it works…
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
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.
The bootloader of my device is unlocked, but critical partitions aren’t. So I can tell you after next OTA if it works…
I’ve just done an OTA update and as expected it worked perfectly (with critical partitions locked).
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.