Are you in fastboot mode when you try to run these commands? On your device, you should see a black screen, with white, red (and green, when the selected option at the top is “START”) text, and with the first red line stating “FASTBOOT MODE”.
If not, you can get there by holding power-button + volume-down for ~3sec (until you see “Fast Boot Mode”).
If that is not the issue: have you downloaded fastboot from the link of the second step?
Note: if you encounter this issue following the update proposed yesterday, I fear that doing those steps won’t help (it is also the case for me).
Could you tell us any way how it went, whether you are able to boot with the slot changed, or if changing the slot do not help?
Yes, I am in exactly in this Fastboot mode that you describe (black screen with white and red text, “Start” on top and first red line is “FASTBOOT MODE”). Is it maybe a problem that in the last line it say “DEVICE STATE LOCKED” also in red letters?
Of course, I will tell you here in this forum my experiences, if the recovery worked for me.
It is not good news that it seems to not have worked for many users…:S
It was quite a shock for me that an official e os update crashed my phone
Okay, I made it now finally to change the slot. On another Windows computer it detected the Fairphone.
Slot B is not loading. I changed it now to Slot A.
What is the right thing to do now to boot the phone from the fastboot mode?
Click enter on the green “START”, the red “Restart Bootloader”, the red “Recovery mode” or the white “Power off”?
Thanks a lot for yor help already 16NoCo and AnotherElk
Okay, the end of the story is that I also have no success in booting my FP3 with this mechanism.
I tried to reboot the e OS Android system with both slots A and B, clicking either on “START” or “POWER OFF” in the fastboot mode after I have successfully typed in the commands “fastboot getvar current-slot” and “fastboot --set-active=a” or (with b in the other case) in the Windows terminal.
So, what do you guys do right now? The only option seems to be a factory data reset to get the Fairphone working again, no? In the meanwhile I have switched back to my old iPhone again.
Really a pity: i was looking forward that the Corona Warn App would finally work with microG on e OS after the update and now this crash.
I am waiting for reply from /e/ devs, to see if there is anything that can be done…
This is some kind of “new issue” so it seems normal that nobody pointed directly to the solution.
In the meantime I also use my old (old old) phone.
So was I (for my local equivalent of Corona Warn)… that’s why I did not ask myself any question before updating, although I had seen that people had issue with the previous update (but I thought that this update ought to fix those issues).
And I’m not sure that this update was the one that would have fixed microG. In fact, it is still version 0.12 and I guess the microG update was expected for 0.13(?)
tanks for your help, though! Whats supposed to happen now? Are we waiting on the /e/-support to come up with a solution or do we have to just erase our data?
If you really need your data on the phone (= no backup), you wait.
If you have the time and want to wait, you wait.
If you don’t have the time or don’t want to wait, you erase your data.
I’m really concerned now about how /e/ handle updates, this update doesn’t look good, and the process of testing and rolling it out doesn’t look good at all.
Ok, so the USB connection is working at least, that’s something.
The adb command doesn’t work in Fastboot Mode, so that’s to be expected, but the fastboot command should work.
Just to make sure … The phone really is in Fastboot mode when you get this? Here’s an example picture from [HOW-TO] Flash /e/-OS on Fairphone 3 using Debian based GNU/Linux … displayed data may vary …
I experienced Fastboot as being more robust than ADB so far, so it’s a bit odd to see it reported the other way around. If on Windows, there could still be driver trouble which could be avoided.
Apart from the fact that there were partly malfunctioning fastboot commands around in Linux distributions for a while and therefore really the current tools directly from Google should be used, I can’t troubleshoot this on Linux.
I’m a bit confused about this. Is there any “official” information channel to watch for these kind of things? The gitlab release notes linked on https://images.ecloud.global/dev/FP3/ are not really helpful. How would I even connect a version number as shown in my settings to a specific commit on gitlab?
Currently running on 0.12-2020093076095, and havn’t had problems yet. Should I revert to the other slot and downgrade to the latest official version (as the one I’m running has been retracted), or just wait it out until a new version becomes available as OTA upgrade? Clearly there seems to be something fishy about the September version, and I don’t want to find myself stuck with a bricked device after the next update. Scary that even the A/B fallback seems to be broken in some cases.
I would say if the build you’re on works for you, then don’t change it for the time being, neither upwards nor downwards.
When an update comes around, wait a few days to see whether there’s any drama to perhaps stay clear of.
You can’t prevent technical failure 100%, but you can make it less troubling, if it actually happens.
Back up regularly any data which is important to you.
If technically possible, have a look into the backups to see whether backing up actually worked.
Don’t update when on the road or in any time constraints, if possible. Be prepared and take your time for an update.
When an update comes around and you’re not comfortable in the early adopter role, wait a few days to see whether there’s any drama to perhaps stay clear of.
Make sure to use the fastboot command from the current Android SDK Platform Tools and to enter the commands correctly (a screenshot would help to see whether there’s anything to notice).
With unlocking the bootloader, you confirmed a factory reset (it’s a security feature). Your data is now gone.
I’m employing a little trade-off for that currently.
I’m running /e/ with an unlocked bootloader (with encrypted data, though, so data should not be accessible in case of simple loss or theft), so I can do this …
