Fix for bootloop issues with FP3

Recently some of our users have reported an issue on the FP3 pie build with the device bootlooping post and update. As a fix to this we have created a document which can be accessed here
https://doc.e.foundation/how-tos/FP3-fix-bootloop-issue

Pl share your feedback in this thread in case there are still issues.

Regain your privacy! Adopt /e/ the unGoogled mobile OS and online servicesphone

5 Likes

Thank you for the documentation. I’m seeing a typo “resinstall” in the 3rd step

This will not work when bootloader is locked, or is this article for “manuall” applied updates that went wrong?

Indeed, like other people, I got this issue because I updated OTA. So I did not need to have my bootloader unlocked.
And thus trying those commands yields FAILED (remote: 'Partition flashing is not allowed').

Is there no option to apply an “update” form Recovery mode > Apply update > Apply from ADB?

Wouldn’t it be a “smart” solution to enable bootloader unlocking in the developer options before installing an update OTA to have the option just in case to use fastboot flash commands?

That would still require to unlock afterward, and thus lose data, rigth?
Then I would not need what is explained in the above link, because a factory reset would have the same effect.

Tell me if I’m wrong.

And anyway, I think that I will change some things in how I perform updates and backup my data after this experience…
What I want to know is how to get out of the situation I’m in (if there is a way). Not only to know how I could have done before the issue to be able to get out of it.

Yes that is true … It is just an emergency measure in my eyes if the factory reset is not able to return the phone to a bootable device :wink:

1 Like

The short answer: No. The locked bootloader is a feature, not a bug. It prevents unauthorized people from reading your data via a fastboot - recovery attempt. You can’t avoid deleting ALL data when you unlock the bootloader. Sorry… I had to learn this lesson after updating /e/. After this (;-)) I unlocked the bootloader, changed the OS and reinstalled all APPs and data.

1 Like

And so what about adb sideload?
Is there a chance that it would work, without erasing my data?
I see that, with fastboot flash, we do not flash userdata.img. If I can sideloud, should I delete this userdata.img file and create a new .zip without it, and then sideload this new zip?

Thanks again for your answers

According to my experience, a locked bootloader also prevents sideload processes. In my case, nether adb sideload nor fastboot had ANY access to the partitions of the phone.

1 Like

I just discovered something!
When booting in recovery mode from the slot with 0.12-q (which has more option than the default LOS recovery mode), I can “Enable ADB”.

With this, my computer detects my device in ‘recovery’:

$ adb devices
List of devices attached
A209G8MN0202	recovery

This would not let me use adb backup (because it requires to unlock the device and accept on a prompt on the screen), but I can enter adb shell and from there, here is what I can see or not:

  • /data, /storage and /sdcard are shown as empty. That was where I guessed first that I could find my data.
  • /dev/block/platform/soc/7824900.sdhci/by-name and /dev/block/by-name are both accessible, and running ls -la in those directories show that the partitions are links to /dev/block/mmcblk0*** in both cases (what’s the difference?).

I was able to adb pull /dev/…/userdata (a huge 49GB file). I could also directly pull everything with mmcblk0.

So, here are my questions:

  • Is it enough to have retrieved userdata if I want to have my data back in place?
  • If not, what should I pull in addition? All mmcklk0, or not? (Since I don’t know how the retrieved file will be structured, I don’t know if I would be able to restore only the partitions that I want. Because restoring the images that are corrupted seems useless)
  • If I can retrieve something like that, how should I proceed to restore it afterwards?
    I’m thinking of somehow following this procedure by @AnotherElk (I will mention this as [1]): reinstalling the /e/ version I had before the update (0.12-p-2020093076095-dev-FP3), but leaving my bootloader unlocked, setting up the same screen lock as before, and then restoring the partitions using TWRP.
    • Does it seem correct to do that?
    • On what slot should I be reinstalling? The one with the update (as in [1]), the other one, or both (as in the documentation link of the original post here)?
    • This does not include /data/media, as said in [1]. Is it possible that there would be something in this directory, if I see /data as empty? Note that I do not have an SD card, and judging from the size of userdata, I should have most of my stuff in the latter.
  • Even better: would it be possible to write the correct boot images to the system using the adb recovery mode? So that I would not need to wipe and reinstall everything :slight_smile:
  • If it is not possible to recover everything with this, do you think of anything else that would do the trick using adb recovery?

Thanks again to all for your help.
I’m confident (or really hoping) that I’m into a solution :sweat_smile:

Note that I did not perform anything special to set up encryption. (I only have set up a schema to unlock the screen.)
Thus, is their any encryption in the userdata that I have pulled?

I don’t know if that changes something, except the fact that I would not be constrained by setting the set unlock schema. But wanted to add this to make clear that I don’t know if I have encryption.

Settings - Security & location - Encryption & credentials (it already says “Encrypted” below this, but anyway …) - Encrypt phone … says “Encrypted” and doesn’t let you proceed.

It is my understanding the Fairphone 3 is encrypted by default, most likely an Android requirement nowadays, but I didn’t find an easily confirming source quickly just now.

As was the case in earlier Android versions, the only partition to really be encrypted is the data partition (aka userdata).

adb backup is deprecated (and unreliable if you want to believe the internet and my personal experience), so you are not missing much :wink: .

This is at the same time the decryption password for the data partition, e.g. TWRP would prompt for this before being able to access the data partition.

If you didn’t provide a password this should be encrypted, or is my thinking wrong?
Is there a way to have a look at the contents in it on the computer?

1 Like

If you use linux you can try to mount your saved data:
sudo mount -o loop data.img data

3 Likes

Do you know if there is a way to provide a password when using adb pull? I didn’t find any with the Internet search I’ve been trying…

I tried that with the userdata image, and here is the output of ls.
So all these folders can be seen without password, but the content of all of these folders are hidden to my computer (e.g. ls data yields ls: cannot open directory 'data': Permission denied).

But is it a problem that it is encrypted? If I reinstall the same build as before, and the same screen lock as before, then I could just sent my previous (encrypted) userdata to my device using TWRP, and my device should be able to use it correctly(?) Isn’t it what you said in [1]?

If you think that I have to decrypt my data first, I just found this guide to retrieve encrypted data (for Mate 9). Do you think I could do something like this in my case?

Does that mean that the system partitions are also encrypted, and that this would be the reason why I could not adb push the boot and other system images in order to ‘repair’ the current build?
Note: I did not try to do that yet, I will wait a bit more to see if someone among you tell me to do it (and how) or not.

I don’t know … I could have imagined this going two ways …
a) adb pulls decrypted data after prompting for the decryption password, much like TWRP accesses the data partition.
b) adb pulls encrypted data and any means to access this outside of the phone would have to provide decryption capability.

Could be file-based encryption, but I don’t know. Anyway …

Sure, I just thought having a look into the image on the computer, if technically possible, could tell you whether you have encryption.

I can’t say for certain for any obscure partitions I probably don’t even know are there because a user doesn’t have to deal with them, if there are any such things, but no, the system partition and the others you deal with when installing /e/ are not encrypted. The data partition is, and that’s where all your user data is.

1 Like

Okay nice. So I think I will do that.
Except (once again) if I’m able to repair my current system:

So do you think I could try to adb push fresh_eos_build/boot.img /dev/block/mmcblk027 (27 is where the link of the current /dev/block/by-name/boot_a points at),
and do this with all the images that are asked to be flashed in the documentation that Manoj posted?
i.e. system, boot, vendor, product, dtbo and vbmeta; all of those both with _a and _b suffixes.

It seems that I am able to write to my device, at least within the adb shell (edit: I tried to adb push random document, and this works too).

I tried compare the boot image on my device (not updated slot) with the ‘clean’ one, to see if there was an encryption, or anything that modifies it.
So here I show an screenshot of those files opened with a text editor… it is not made for that, but they seem at least to be under the same format.

I honestly don’t know.

1 Like

If I’m able to play with adb as I want (somehow bypassing locked bootloader and TWRP installation), this serves me well in my current situation…
But this would be a security breach…

As you mentioned, having an unlocked bootloader, even with data encryption, is unsafe.
About that, do you still use an unlocked bootloader now? Or do you have another solution to be able to (e.g.) boot into TWRP?

I will try to contact directly the devs after having resolved my problem (maybe this breach is only available in the build I got).

Anyway, I will try to stop bothering you with stuff you can’t answer :sweat_smile:
Thanks a lot for all the help you provided!

In my understanding it is unsafe in an extremely unlikely event for the average user, which I consider myself to be. That makes this just individual risk assessment.

Yes.

1 Like