[Solved] Problem to unlock device via fastboot on FP4

what version?
C2C or A2C?

fastboot is evil in this regard , unfortunately your best bet is to try all possible USB cable, USB port, computer combinations you have available.

My laptop does not recognize my FP4 using fastboot - adb works - but using the same cable with the same port with a different phone works just fine. Using the very same cable my server recognizes both phones using any USB port :confused:

Heck, my server doesn’t care if I use a 10m extension cable in between xD

1 Like

I tried with another cable but the answers are the same : adb work and not fastboot

I only have A2C cable


I tried with th second usb plug and my 2 cables, but the answers are the same

I reboot FP4 on another USB plug with 3 3rd cable :

$fastboot devices 
[number]       fastboot
$fastboot flashing unlock              
OKAY [  0.035s]
finished. total time: 0.035s

FP4 is rebooting


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

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 :

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 :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.