It wasn’t, the microG update got delayed further.
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.
Thanks to the entire team for all the efforts that you are doing.
By not detected you mean you are using the current Android SDK Platform Tools, and
fastboot devices just delivers a blank line?
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.
firstname.lastname@example.org ? at least 20 characters
Thx a lot, that worked for me. I got an update message in my fp3 and thought that would be safe to use (stupid me).
Everything is working again, but the question is: how can I prevent this situation?
It has an eOs update from 29th October
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.
Do you have suggestions for backing up my whole fp3 (like Apple is doing it)? To my personal cloud or anywhere (no e-cloud please)
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 …
I’ve just seen your procedure, after getting an answer from a dev on GitLab about the situation I’m on…
So for you it is not possible to do something like this with a locked bootloader and without TWRP?
I’ve mentioned your backup procedure on the GitLab issue, asking the devs if they thought I could do something like that in my case.
Could you answer on GitLab if you’ve got an account, and have something to answer? (I could not find your username to tag you)
No. I need to have the bootloader unlocked in order to be able to boot TWRP with fastboot when I need it. A locked bootloader doesn’t let you do this.
If the next question would be about installing TWRP …
… If I remember right, it wouldn’t work to install TWRP (altering the boot partition) and then lock the bootloader again anyway, because the phone wouldn’t boot then, but I don’t find a reference for this just now quickly.
Okay, thank you.
And even though, I would need to unlock the bootloader at first, which would result in wiping my data… which is exactly what I try not to do, since I want to do that in order to backup my data.
Am I right? Or not entirely?
Correct, unlocking as well as locking the bootloader will force a factory reset for security reasons.
I want to add this: after changing the boot partition try to boot multiple times >3 I know a user where that helped! (if it does not boot the first time)