I tried it also with twrp and I have the same problem !
The flashing of the temporarily booting image is fine but the phone won’t reboot
fastboot boot /Users/eboelens/Downloads/twrp.img
Sending ‘boot.img’ (98304 KB) OKAY [ 2.114s]
Booting OKAY [ 10.381s]
you are on the paragraph Temporarily Booting a custom recovery using fastboot
Am I correct so far?
Is the failure at this point?
Manually reboot into recovery mode
We see this tip:
Tip: Outdated fastboot releases dropped legacy A/B support, so it might attempt to flash to boot__a / boot__b rather than boot_a / boot_b if you try to flash boot. In this case, you must update fastboot to a release newer than or equal to 31.0.2. Alternatively, you can manually specify which slot to flash to based on what slot fastboot failed to flash to. For example, if fastboot fails to flash to boot__a, you must flash to boot_a.
Are you fully certain of all the points raised here?
Are there any specific questions you have about these points?
thank you so much for helping
Yes to all except the tip maybe.
I dont really understand
You can see the flash is on OKAY on boot_a
I’m under the impression that it’s ok
correct ?
or not ?
If thats the reason i will look for the right version
at the moment I’m on OSX and using Homebrew:
adb help
Android Debug Bridge version 1.0.41
Version 29.0.4-5871666,
maybe it is better using the platform tools manually ?
is that the right direction that I have to go?
Using the Android Developers tools, you are not really installing platform tools; you are just providing them.
You are being confused; when you called fastboot, you still called “system” fastboot, or put another way, fastboot as originally installed by the system.
Newer versions always get a larger version number. Sorry,
A demo
I have no system platform tools.
Let’s use the command which to look for properly installed adb
iain@laptop:~$ which adb
iain@laptop:~$
Tells us – absent.
My Platform Tools are extracted to ~/platform-tools
iain@laptop:~$ cd platform-tools/
iain@laptop:~/platform-tools$ ./adb --version
Android Debug Bridge version 1.0.41
Version 33.0.1-8253317
Installed as /home/iain/platform-tools/adb
iain@laptop:~/platform-tools$ ./adb devices
List of devices attached
53xxxx54 device
The really significant thing here is the use of
./
… this says “use the command you find in this folder”.
sorry for all your time
i deleted everything from android platform tools from my mac (there was a lot of junk on it)
Reinstalled with homebrew and I’m now on
eboelens@iMacHoofd ~ % adb --version
Android Debug Bridge version 1.0.41
Version 33.0.2-8557947
Installed as /usr/local/bin/adb
tomorrow I will try to install the recovery again…
I will post back
I could have tried to guide you to use latest Platform Tools, while you had older Platform Tools installed within your system.
I feel it is much better that you took this time consuming route. There is more stuff in Platform Tools than just adb and fastboot; we do not need to become confused if any other side issues should emerge, especially as we are aware of the issue described in your instructions as “dropped legacy A/B support”.
I do not know the device, I can imagine that would certainly be the case
BUT
I have learned never to allow an Android device to boot to system – or do anything under the control of Android – while I am trying to flash it.
We know devices vary in their behaviour … but if I were following these instructions I would be very careful to do the two flash jobs … try to force stop the device … and immediately on halt get the Recovery started by button control.
The reason I say this is that while the manufactures system controls the device, it will try its hardest to deflect intrusion.
I tried again flashing twrp with succes this time , reboot again in twrp, and reboot again with the recovery keys ,
factory reset, flashing /e/, reboot , e screen bootloop , reboot into recovery, recovery from /e/ appears , factoryreset, flashing /e/ , reboot and boom I’m in /e/
Sometimes a Factory reset after a “bootloop on First boot” does result in success.
Speculating, somewhat, one explanation for this is that First boot is always hard for a device; sometimes it can take quite a long time. maybe sometimes the device actually cannot manage the task of First boot, and leaves the device unstable.
As it is a First boot, an attempt to “do it like the last successful boot” will also fail – hence the loop.
A Factory reset, allows the device to have another go, fresh!