Shift5me does not boot

[finstreresel]

Hi,

I own a Shift ME5 that, in the weeks leading up to its current state, repeatedly tried to download and install the same update, which filled the storage. I'm not sure if this relates to the current problems, but that seems likely. There are - as I know now - solutions to the update problem, but they require a booting phone.

That I don't have anymore. The phone starts booting normally, but then complains "Can't load Android system. Your data might be corrupt. If you continue to get this message, you may need to perform a factory data reset and delete all user data stored on this device." (see picture) Now I'm very much interested in not performing the factory reset.

I can boot into recovery, but I can not do much there. Adb sees the device as unauthorized - again all fixes seem to require a booting phone. I tried to adb sideload the image for Shift ME5 that should already be installed, but that does not work due to the signature (see image 2). I'm positive my phone is a ME5. Is there any experience with that problem, and is there any hope for my data?

 

[danielp]

Hello finstreresel, welcome to the forum.

I see you have done some research already. You are right, it could be due to storage filling. Next time better consult support or the forum earlier. If it really is about the disk space filling this could have been avoided. A new version of the Updater App was provided which fixed the disk filling error, but to use it the system must be bootable.

The most important question however is if the update finally succeeded and from which exact version (like SOS.1.1.G.20201126) did you try to update and what was the target version (like SOS.1.3.G.2021122).

For new Beta versions there are problems with Adoptable Storage (integration of the memory of the SD card memory into the internal memory) which resulted in exactly the scenario you described. For instance this was reported here.

One option might be using the flashtool to install the desired version and get back to a bootable state. However if the error is in a location not touched by the tool (e. g. the data partition) it wont help and a factory reset ist most likely the only option.

Please note that the active boot slot must be A else the flashtool could render the system completely broken. If this is the case you need to change the slot to A but here a factory reset is also inevitable.

If Adoptable Storage actually is involved I recommend to disable it as soon as possible.

 

[finstreresel]

Thank you for the prompt response!

Next time better consult support or the forum earlier. If it really is about the disk space filling this could have been avoided. A new version of the Updater App was provided which fixed the disk filling error, but to use it the system must be bootable.

In retrospect this seems reasonable. Unfortunately, it wasn't apparent to me that the update failed (there was no indication by the phone, and I didn't remember the numbers at first), and there was no (significant) problem at first.

BTW, the forum seems much more responsive then support. I might have just been lucky here, or unlucky with the support, though.

The most important question however is if the update finally succeeded and from which exact version (like SOS.1.1.G.20201126) did you try to update and what was the target version (like SOS.1.3.G.2021122).

I think it did not succeed. There is no indication of the last attempt yielding a different result. I do not know how to verify this assumption, though. The version number I get it the recovery is 8.0.0/O00623/1592466613. This does not look like the numbers you cite.

For new Beta versions there are problems with Adoptable Storage (integration of the memory of the SD card memory into the internal memory) which resulted in exactly the scenario you described. For instance this was reported here.

I was not running a beta, so this shouldn't apply to me.

One option might be using the flashtool to install the desired version and get back to a bootable state. However if the error is in a location not touched by the tool (e. g. the data partition) it wont help and a factory reset ist most likely the only option.

Please note that the active boot slot must be A else the flashtool could render the system completely broken. If this is the case you need to change the slot to A but here a factory reset is also inevitable.

Is there a way of checking that? It seems that ignoring warning signs is what got me into this mess. I do not think blindly rushing forward, ignoring possible danger, is a reasonable way out.

 

[danielp]

Is there a way of checking that? It seems that ignoring warning signs is what got me into this mess. I do not think blindly rushing forward, ignoring possible danger, is a reasonable way out.

Yes the guide about changing the Slot also explains how to check the current slot.

fastboot getvar current-slot

 

[finstreresel]

Thanks again! I could have found the answer myself...

Unfortunately, I can not quite reproduce the steps in the guide on slots. The reason is that adb sees my device as unauthorized. I found a proposed solution (I don't have a link right now, but I could find it) that suggested copying a public key from ~/.android/adbkey.pub (or similar) to the phone. Unfortunately, I only ever get a private key there.

With the device being unauthorized, I can not run adb reboot bootloader. Also, fastboot getvar current-slot seems to be waiting for the device to be visible ("< waiting for any device >")

 

[danielp]

Could be a driver issue. Did you check the prerequisites? Also in the following posts someone else had similar problems. Unfortunately there was no feedback or confirmation if the suggestions did help. I only tested this on a Linux system and had no such issues.

 

[finstreresel]

Hi,

I sorry for the late response, the change of year disturbed my schedule. In the same vein, happy new year.

Regarding the prerequisites: I'm not actually sure if the bootloader is unlocked I just figured I'll try to follow the steps as best I can. Which is not very good, aparently.
The phone is not rooted, but that is not listed as a prerequisite.

I also normally use a Linux system, a Debian Testing with adb (and everything else) installed via apt. There I only get a private key. I tried the same in Windows, with the adb zip from Google, and there I got a public key. The happiness about that was short-lived, however, as adb pushing it to the phone failed:

adb: error: failed to get feature set: device unauthorized.
This adb server's $ADB_VENDOR_KEYS is not set
Try 'adb kill-server' if that seems wrong.
Otherwise check for a confirmation dialog on your device.

I was hoping to be able to copy files from the phone. That would be way better than loosing all data already. Then I think I wouldn't mind a factory reset.

I was using two SIM-cards and no SD-card. That would make things easier.

 

[danielp]

Normally you don't need to mess with keys when using ADB. You could try to delete the .android directory on the computer which contains the key and try again.

 

[finstreresel]

Normally you don't need to mess with keys when using ADB. You could try to delete the .android directory on the computer which contains the key and try again.

I tried that in Linux, and it lead to the directory being recreated (with only a private key) with no visible change. Maybe the key changed; I'm not sure.
I think I don't need to mess with the keys if I accepted the fingerprint of the PC on the phone before. In other words if the phone is not unauthorized. In this case the messing with keys is done by someone else, I assume.

Unfortunately, I didn't do that before the phone didn't boot anymore. Then it would have been easy to do.

 

[danielp]

Könnten bitte diejenigen welche von diesem Problem betroffen sind Feedback geben ob das Telefon (bzw. der interne Speicher) verschlüsselt war?
Das sollte unter "Einstellungen -> Sicherheit & Standort -> Verschlüsselung & Anmeldedaten" zu finden sein.

 

[finstreresel]

Das Problem ist ja, wenn man weiß dass man betroffen ist, ist es zu spät um nachzusehen. Die Bitte heißt also eigentlich: Alle Nutzer sollen sich merken, ob ihr Telefon verschlüsselt ist.

Ich schätze meines war es nicht. Aber ich kann mich irren.

 

[danielp]

Die Information die benötigt ist wäre ob die Verschlüsselung standardmäßig aktiviert ist und man sie deaktivieren kann. Oder ob sie deaktiviert ist und man sie aktivieren kann.

Ich denke je nachdem wie die Ausgangssituation war sollte man schon wissen ob man sie deaktiviert oder aktiviert hat.

@amartinz ???

 

[danielp]

Nach Rückfrage hat sich herausgestellt das die Verschlüsselung standardmäßig aktiviert ist und nur mit Root Rechten deaktivierbar ist. Falls das, aus welchen Gründen auch immer, jemand gemacht haben sollte kann er sich gerne hier melden!