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?
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.
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.
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?
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
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 ): 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 ), the other one, or both (as in the documentation link of the original post here)?
This does not include /data/media, as said in . 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
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
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 ?
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.
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.
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.
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
Thanks a lot for all the help you provided!