Batterie nach Update entnommen -> "kInstallDeviceOpenError"

shivagnihotri

shivagnihotri

Active member
Original poster
27 Januar 2022
83
Germany
Namasté und liebe Grüße aus Paraguay, liebe "SHIFTer"!

Ich hoffe sehr ihr könnt mir weiterhelfen, denn ich habe eine dringende Herausforderung zu meistern: Vor wenigen Tagen war ich in Asunción (der Hauptstadt von Paraguay) und zeigte bei einem Gespräch auf Spanisch einem neuen Kumpel mein liebevolles und treues SHIFT6mq. Währenddessen spielte ich über sein WLAN das zu diesem Zeitpunkt neueste Update lineage-19.1-20220824-nightly-axolotl-signed.zip ein. Das Update wurde erfolgreich eingespielt.

Als ich dann voller Freude davon berichtete, daß bei diesem schönen Telefon auch die Batterie zu entfernen sei, entfernte ich diese demonstrativ noch während des ersten Neustarts - ohne mich dabei daran zu erinnern, daß das neue System wenigstens ein mal vollständig hochgefahren werden sollte.

Nun funktioniert das System meines Telefons nicht mehr. Ich erhalte fortlaufend die Fehlermeldung:
Is-It-Possible-To-Recover-the-Cant-Load-Android-System-Issue.png


Als erfahrener Bastler lag mir schon die Lösung auf der Zunge: Einfach in den Recovery-Modus booten und mittels ADB Sideload das Update nochmals drüberbügeln: Doch vergebens, keines der derzeitigen Pakete geht einzuspielen: Wenn ich lineage-19.1-20220810-nightly-axolotl-signed.zip einspielen möchte, erhalte ich "E:Current SPL: 2022-08-05 Target SPL: 2022-07-05 this is considered a downgrade -- E: Denying OTA because it's SPL downgrade" und wenn ich das derzeit immer noch neueste Update nochmals einspielen möchte, dann "Error applying update: 7 (ErrorCode: :kInstallDeviceOpenError)".

Fragen: Was kann ich tun, damit mein System wieder brauchbar wird und ich meine Daten nicht verliere? Gibt es eine Möglichkeit, das Downgrade zuzulassen? Wie behebe ich den "kInstallDeviceOpenError"? Gibt es ein anderes (temporäres) Update, welches sich (vielleicht über einen Spezial-Modus) einpielen lässt?

Die Angelegenheit ist ziemlich delikat und dringlich, denn hier auf der anderen Seite der Erde benötige ich mein Telefon jeden Tag, um mit meiner Familie und Freunden in Verbindung zu bleiben und mich bei meinen Unternehmungen zurecht zu finden. Meine Daten sind auch unverzichtbar. Bitte helft mir schnell!

Beste Grüße aus Paraguay,

Euer shivagnihotri.
 
shivagnihotri schrieb:
Zunächst würde ich gern wissen, ob meine leere SD-Karte nun bedeutet, daß alle Bilder, Videos und Daten verschwunden sind.
Zum Vergrößern anklicken....
Der Interne Gerätespeicher ist Standardmäßig verschlüsselt. Über den kannst du keine Daten von Außerhalb ohne Keyfile holen. Eine zusätzliche externe SD-Karte sollte aus dem Recovery oder Fastboot nicht löschbar sein.
Wenn eine externe SD leer ist und es nicht sein sollte wäre das seltsam.
Greetz
 
  • Like
Reaktionen: Martin S. und shivagnihotri
Moin Leute,
für jede*n die es interessiert hier ein kurzer Zwischenstand des Problems:

Nachdem der UB-Ports-Installer die Fehlermeldung "Error: Wiping super failed" raushaute nahm ich an, dass der Fehler mehr bei der Super-Partition als bei der /userdata Partition liegt.

Lange Rede: Wir haben sie ersetzt (auf eine ShiftOS Partition in beiden Slots. @NoG....eFan hat ja schon durch seine Tests bewiesen, dass die Geräteverschlüsselung des ShiftOS zu LineageOS kompatibel ist) mit der Absicht über ein ADB-Sideload direkt ohne Neustart LineageOS zu installieren, damit es hier zu keinen Cache-Problemen kommt.

Das ADB- Sideload der LineageOS-ZIP kam zu einer Identischen Fehlermeldung wie vorher auch. Somit hat das ersetzen der Super-Partition nicht den gewünschten Effekt gehabt.

Netzrecherchen zeigten, dass der "kinstalldeviceopenerror" zumeist in Verbindung von Custom-Roms und Installationen oder Updates in Zusammenhang mit ADB-Sideload auftraten. Lösungsansätze gab es hierzu eher weniger. Wie so oft wurde ein Full-Wipe empfohlen. Kommt leider hier erstmal nicht in Frage.
Ich hatte die Idee, ggfs mal die Update-Zip nicht zu sideloaden sondern direkt über die externe SD-Karte zu installieren.

Seltsamerweise bot das LineageOS-Recovery auf dem Betroffenen Gerät die Möglichkeit eine ZIP von der externen SD-Karte zu installieren auch nicht an. Bei meinem Gerät läuft es mit den selben Konditionen (letztes Lineage-Recovery, Fat32 SD).

Nächster Ansatz: Starten des Betriebssystems mit ShiftOS-Bootimage um zumindest nach dem Start die Daten zu sichern. Danach kann man ja immernoch alles platt machen.

Also kurzer Versuch: Flashen des originalen ShiftOS-Boot.img.

Das System startet. Die Bootanimation (ShiftOS und nicht mehr LineageOS, Wechsel der Super-Partition war also erfolgreich) wird angezeigt, ein Zugriff auf /system und /product findet also statt.
Trotzdem irgendwann vor beenden des Bootvorganges der Fehler "Can't load android system" und ein Abbruch.

Jetzt sind wir am Rätseln. Liegt es vll. doch an der Userdata-Partition, die an irgendeinem Punkt nicht gemountet werden kann oder ist das Problem vielschichtiger.

Im Prinzip haben wir das Betriebssystem gewechselt. Das Resultat bleibt das gleiche.

Updates können nicht durchgeführt und Installiert werden. Der Bootvorgang bricht ab.
Die Bootanimation zeigt aber, dass auf die System-Partition prinzipiell mal zugegriffen werden kann.

Kennt einer von euch ne Möglichkeit ein Live-Log beim Booten auf dem PC mitzuschneiden?
Auf das Gerät haben wir ja derzeit keinen Zugriff.

Vll hat einer von euch noch eine Idee was man sonst so ausprobieren könnte.
Ich kann mir nämlich fast nicht vorstellen, dass der Shift-Support bei einem LineageOS-Verursachten Problem ne andere Idee einwirft als einen Full-Wipe.

Greetz
 
  • Like
Reaktionen: duckface, jefla, Uli und 4 andere
Besteht vielleicht die Möglichkeit, einmalig TWRP über fastboot zu booten? Der interne Speicher sollte ja automatisch gemounted werden. Dann könnte man versuchen, über "adb pull" die Daten von /storage bzw. /sdcard auf den PC zu kopieren.
Wenn das klappt, würde ja (wenn ich das richtig verstanden habe) einem full wipe nichts mehr im Wege stehen, oder?
 
Leider nein, für die Shiftphones gibt es keine Recoverys, die den internen Speicher mounten können.
Greetz
 
Vielleicht kann man ja versuchen, das manuell über adb shell zu mounten. Ob da jetzt TWRP oder LOS-Recovery die bessere Wahl ist, kann ich nicht beurteilen. Eine weitere Frage wäre da vermutlich, ob es Device oder File Encryption ist. Aber das ist vielleicht einen Versuch wert.

Ich glaube amartinz könnte Dir da vielleicht helfen.
 
  • Like
Reaktionen: shivagnihotri und @Lhotze
Dagaz schrieb:
Vielleicht kann man ja versuchen, das manuell über adb shell zu mounten. Ob da jetzt TWRP oder LOS-Recovery die bessere Wahl ist, kann ich nicht beurteilen. Eine weitere Frage wäre da vermutlich, ob es Device oder File Encryption ist. Aber das ist vielleicht einen Versuch wert.

Ich glaube amartinz könnte Dir da vielleicht helfen.
Zum Vergrößern anklicken....
Danke, daß ihr mir wieder Hoffnung macht. Das würde ich sehr gerne ausprobieren. Ich stehe mit @Lhotze über Telegram in Verbindung und nehme gern alle Ratschläge entgegen, die ihr hier reinschreibt und die er von Euch auf anderen Wegen erhält. Hoffe @amartinz unterstützt uns.
 
Seltsame Sache: Wenn ich das offizielle ShiftOS-Recovery verwende und ShiftOS installiere, funktioniert das zur Überraschung von @Lhotze und mir anstandslos. Dennoch fährt das System nicht hoch, selbiger Fehler, Android kann nicht gestartet werden. Hat noch jemand Ideen, was ich probieren könnte? Habe den Support bereits mittels E-Post und über das Kontaktformular angeschrieben, sich doch bitte hier einzubringen.
 
  • Like
Reaktionen: @Lhotze
shivagnihotri schrieb:
Seltsame Sache: Wenn ich das offizielle ShiftOS-Recovery verwende und ShiftOS installiere, funktioniert das zur Überraschung von @Lhotze und mir anstandslos
Zum Vergrößern anklicken....
vermutlich weil du ohne Full Wipe das Handy nicht starten kannst. Aber damit verlierst du halt wieder alle Daten. War bei meinen Tests auch so. Immer wenn du das OS wechselst, will das Handy einen Full Wipe. Aber wenn ihr das Shift OS drauf bekommen habt, stellt sich mir die Frage warum ihr nicht wie im 1.Post von dir beschrieben das Lineage drauf macht. Dann bräuchtest du ja den Fullwipe nicht, oder?!?
 
Das geht leider nicht.
Ersetzen der "Super-Partition" mit ner LineageOS-Super führt ebenfalls zu der Meldung, dass das System nicht geladen werden kann, obwohl es über die Bootanimation hinaus bootet.
Wenn (nach einer ShiftOS-Light Installation) wieder versucht wird LineageOS zu installieren lautet der Fehler wieder "kInstallDeviceOpenError". Der Fehler hat also wahrscheinlich nicht nur was mit LineageOS zu tun, sondern auch mit dem ADB-Zusammenspiel mit dem LineageOS-Recovery / der Installation von SD-Karte. Ungeachtet bin ich der Meinung, dass eine Neuinstallation von LineageOS den Fehler gegebenenfalls gar nicht beheben können dürfte. Stutzig macht mich tatsächlich, dass a) ShiftOS problemfrei zu installieren geht und b) beim Start zwar gesagt wird, dass auf System nicht zugegriffen werden kann, allerdings die Bootanimation abgespielt wird (die bei ShiftOS auf der /product Partition und bei LineageOS auf der /System Partition liegt.

Greetz
 
  • Like
Reaktionen: shivagnihotri und NoG....eFan
Liebe Leserinnen und Leser, lieber Shift-Support,

in der Hoffnung, daß Euch noch weitere Ideen zur Repartur meiner offensichtlich beschädigten Datenpartition einfallen und mit dem guten Gewissen, daß folgende Schritte vielleicht jemandem anderen weiter helfen, veröffentliche ich jetzt hier den Lösungsansatz von @Lhotze:

  • Sicherung der Partitionen metadata.img und userdata.img mittels ADB auf einem Datenspeicher mit 120 GB
adb pull /dev/block/sda8 /pfad-zur-ablage/metadata.img
adb pull /dev/block/sda9 /pfad-zur-ablage/userdata.img
  • Sicherung vollständig? Dann über die Recovery den vermiedenen Factory Reset durchführen
Recovery -> Factory reset
  • Reboot in fastboot und dort Löschung der userdata.img (und metadata.img) vom Gerät
fastboot -w
  • Im Recovery jetzt das neue System (in meinem Falle LineageOS) wieder einspielen
Recovery -> Apply update -> System von SD-Karte oder mittels ADB Sideload installieren
  • Reboot zurück in fastboot und die Sicherung der metadata.img und userdata.img wieder einspielen
fastboot flash metadata /pfad-zur-ablage/metadata.img
fastboot flash userdata /pfad-zur-ablage/userdata.img
  • Neustart. Im Idealfall sollten jetzt alle Daten wieder da sein. Doch bei mir sieht es jetzt (wieder) so aus:
Is-It-Possible-To-Recover-the-Cant-Load-Android-System-Issue.png


Wenn ich jetzt versuche, über die Recovery das LineageOS nochmal zu installieren, erhalte ich wieder "kInstallDeviceOpenError". Es sieht also ganz danach aus, als ob irgendetwas mit meiner Datenpartition nicht stimmt. Ist das reparabel? Kann ich die irgendwie auf Fehler prüfen?
 
Zuletzt bearbeitet:
Ergänzend muss gesagt sein, dass der genutzte Weg funktioniert.

Im Ordner /metadata/vold/metadata_encryption/key liegen (unverschlüsselt) die Daten, die zum Entschlüsseln der Datenpartition notwendig sind.

Ein sichern der Partitionen /metadata und /userdata führt zu einem vollständigen (verschlüsselten) und riesengroßen Backup der eigenen Dateien. Wie @shivagnihotri schon sagte, etwa 109 GB für /userdata und ein paar MB für /metadata.

Rückspielen beider Partitionen mittels "ADB push" im LineageOS-Recovery oder eben über "fastboot flash" funktioniert. Selbst getestet. Empfehle selten etwas, was ich nicht nachvollziehen kann 😉.

Gab bei mir nur einmal (habe den Vorgang zweimal durchgeführt und dabei auch noch Ubuntu Touch und PostmarketOS angetestet) Probleme mit dem Entsperrcode, ein Verhalten, was ich aber von Datenpartitionsbackups kenne. Nichts was sich entweder über ein Recovery, was verschlüsselte Daten mounten kann oder "Adb shell su", also ADB im System als Root lösen lässt. Wer den beschriebenen Weg also als Backup-Lösung nutzen will, sollte entweder ADB-Root zulassen, eher aber den Entsperrcode entfernen. Der Code wird nämlich (anders als in einem TWRP) beim Systemstart je nach Umständen nicht mehr erkannt.

Greetz
 
Zuletzt bearbeitet:
  • Like
Reaktionen: shivagnihotri
Schon probiert das Lineage OTA zu extrahieren, den Payload in eigentliche Partitionen umzuwandeln, welche dann via `fastboot` geflasht werden können?
Übrigens nutzt Lineage Virtual A/B, das könnte erklären, warum die erste Installation klappt, die zweite aber nicht mehr.

Ich vermute aber, dass durch das Entfernen des Akkus nicht die Systemdateien beschädigt wurden (könnte mit einem Slot Wechsel herausgefunden werden), sondern die Userdata Partition korrupt wurde.
Das heißt ein Factory Reset wäre notwendig.. :(

@Lhotze schrieb:
Im Ordner /metadata/vold/metadata_encryption/key liegen (unverschlüsselt) die Daten, die zum Entschlüsseln der Datenpartition notwendig sind.
Zum Vergrößern anklicken....
Die richtigen Keys zum Entschlüsseln der Datenpartition sind im TEE hinterlegt, Metadata Encryption ist wieder was Anderes:

Android 9 introduced support for metadata encryption. With metadata encryption, a single key present at boot time encrypts whatever content is not encrypted by FBE. This key is protected by Keymaster, which in turn is protected by verified boot.
Zum Vergrößern anklicken....
 
  • Like
Reaktionen: shivagnihotri
amartinz schrieb:
Schon probiert das Lineage OTA zu extrahieren, den Payload in eigentliche Partitionen umzuwandeln, welche dann via `fastboot` geflasht werden können?
Zum Vergrößern anklicken....
Danke für Deine Unterstützung, lieber @amartinz. (y) Nein, was Du sagst habe ich noch nicht probiert. Wie mache ich das genau? Zudem habe ich durch das zurückspielen der Datenpartition schon mehrfach einen Factory Reset machen müssen. Habe also nur noch die Sicherung von metadata.img und userdata.img - komme ich da noch irgendwie an dieses TEE ran, oder sind damit jetzt alle Rettungen hinfällig? 😢
 
amartinz schrieb:
Ich vermute aber, dass durch das Entfernen des Akkus nicht die Systemdateien beschädigt wurden (könnte mit einem Slot Wechsel herausgefunden werden), sondern die Userdata Partition korrupt wurde.
Das heißt ein Factory Reset wäre notwendig.. :(
Zum Vergrößern anklicken....
Höre ich da raus, dass du (wie ich mittlerweile auch) der Meinung bist, das da nichts mehr zu retten ist?

Mach anfänglicher Einschätzung, dass es die Datenpartition ist und viel try rund um die Systemdaten (wir haben die payload-Variante nicht genutzt, aber nach einem Full-Wipe lässt sich alles regulär installieren, was diese Möglichkeit ja obsolet erscheinen lässt 😉) bin ich jetzt deutlich der Meinung, dass da nichts mehr an Daten zu retten ist.


amartinz schrieb:
Die richtigen Keys zum Entschlüsseln der Datenpartition sind im TEE hinterlegt, Metadata Encryption ist wieder was Anderes:
Zum Vergrößern anklicken....
Das war mir nicht bewusst. Ein Blick in die Recovery.fstab indizierte mir im Bereich Userdata, dass die entsprechenden ICS Keys in der /metadata liegen. Oder ist das noch ein Android 10 Relikt?

Your data lives here, treat it well :-)
/dev/block/bootdevice/by-name/userdata /data f2fs noatime,nosuid,nodev,discard,reserve_root=32768,resgid=1065,fsync_mode=nobarrier latemount,wait,check,resize,quota,formattable,fileencryption=ice,reservedsize=128M,sysfs_path=/sys/devices/platform/soc/1d84000.ufshc,keydirectory=/metadata/vold/metadata_encryption,checkpoint=fs

Vermute dann mal, dass TEE in der Userdata abgelegt ist? Immerhin war es mir möglich das System nach Ubuntu-Touch und PostmarketOS nach einspielen dieser beiden Partitionen wiederherstellen?

Eine letzte Einschätzung würde mir noch helfen:

Ist die Verschlüsselung vom aktuell genutzten Build abhängig?
Wir haben das System auf LOS 31.08. gehoben und versucht zu starten. Der Fehler trat auf bei einem Wechsel von LOS 10.08. zu LOS 24.08.

Würde es helfen ggfs wieder auf 10.08 downzugraden und es dann noch einmal zu versuchen oder sind das drei verschwendete Stunden?

Greetz
 
shivagnihotri schrieb:
komme ich da noch irgendwie an dieses TEE ran, oder sind damit jetzt alle Rettungen hinfällig? 😢
Zum Vergrößern anklicken....
@Lhotze schrieb:
Vermute dann mal, dass TEE in der Userdata abgelegt ist? Immerhin war es mir möglich das System nach Ubuntu-Touch und PostmarketOS nach einspielen dieser beiden Partitionen wiederherstellen?
Zum Vergrößern anklicken....
TEE (Trusted Execution Environment) ist abgesondert vom restlichen System und es kann nicht direkt darauf zugegriffen werden (siehe QTEE für Qualcomm).

Ein "Wiederherstellen" von UT und pmOS ist möglich, weil die nicht mit der TEE interagieren.

@Lhotze schrieb:
Höre ich da raus, dass du (wie ich mittlerweile auch) der Meinung bist, das da nichts mehr zu retten ist?
Zum Vergrößern anklicken....
Zumindest sind die Backup/Restore und Wiederherstellungs-Themen immer sehr kompliziert, zeitaufwändig und führen meistens ins Leere.

@Lhotze schrieb:
Ist die Verschlüsselung vom aktuell genutzten Build abhängig?
Wir haben das System auf LOS 31.08. gehoben und versucht zu starten. Der Fehler trat auf bei einem Wechsel von LOS 10.08. zu LOS 24.08.

Würde es helfen ggfs wieder auf 10.08 downzugraden und es dann noch einmal zu versuchen oder sind das drei verschwendete Stunden?
Zum Vergrößern anklicken....
Nein, unterschiedliche Builds sollten keinen Einfluss drauf haben, solange sie vom selben Grundsystem ausgehen (ShiftOS-G, L, LineageOS, CalyxOS, ...) wäre also im besten Fall verschwendete Zeit.

Ich würde eher empfehlen, speziell wenn LineageOS genutzt wird, Seedvault zu nutzen und regelmäßige Backups auf eine SD-Karte zu erstellen bzw. via USB-Stick zu sichern.
 
  • Like
Reaktionen: shivagnihotri und @Lhotze
Was noch zum Probieren wäre, in der Recovery via adb shell versuchen einen Userdata Checkpoint wiederherzustellen:
  • vdc checkpoint restoreCheckpoint /dev/block/sda9
Ich weiß aber nicht zu 100% ob vold in der Recovery läuft und somit vdc funktioniert.
 
  • Like
Reaktionen: shivagnihotri und @Lhotze
amartinz schrieb:
Was noch zum Probieren wäre, in der Recovery via adb shell versuchen einen Userdata Checkpoint wiederherzustellen:
  • vdc checkpoint restoreCheckpoint /dev/block/sda9
Ich weiß aber nicht zu 100% ob vold in der Recovery läuft und somit vdc funktioniert.
Zum Vergrößern anklicken....
┌─[✗]─[shivagnihotri@parrot]─[~] └──╼ $adb shell * daemon not running; starting now at tcp:5037 * daemon started successfully axolotl:/ # vdc checkpoint restoreCheckpoint /dev/block/sda9 /system/bin/sh: vdc: inaccessible or not found

Das Resultat sieht noch nicht vielversprechend aus. Oder mache ich was falsch? Ich bin jederzeit für weitere (auch verrückte) Ideen offen.
 
Zuletzt bearbeitet:
Ganz dunkel, aber ich glaube, vdc benötigt root.
Man müsste - vorausgesetzt ich erinnere mich richt! - vor der Ausführung des Befehls "vdc" erst "su" ausgeführt werden, um root rechte zu bekommen. (Unterstellt, es gibt su auf dem Gerät.) (Es ist aber Jahre her, dass ich vdc zuletzt benutzt habe.)
 
Eine andere Idee von @Lhotze war, daß ich vielleicht irgendwie die userdata.img entpacken könnte, dann hätte ich jedoch weiterhin verschlüsselte Einzeldaten. Aber ohne zu wissen, welche davon was sind, kannst ich sie auch nicht manuell in das System schieben. Ich bin weiterhin gewillt, alles auszuprobieren, was Euch einfällt. Aber so wie es aussieht, gehen uns die Ideen aus. Hast Du noch welche, @amartinz?
 
Ich glaube es ist an der Zeit der Realität ins Auge zu sehen und dich damit abzufinden das die Daten weg sind. Genieße deine Zeit in Paraguay und richte bei Zeiten das Telefon neu ein. So ist deine Zeit sicher besser investiert.

Man kann über verlorene Daten hinwegkommen. Es sind nur Daten. Glaub mir ich spreche aus Erfahrung. Deswegen überlege dir lieber ein Konzept zur regelmäßigen Datensicherung. Dann ist der "Verlust" beim nächsten Mal nicht so groß. Mit Lineage hast zumindest Seedvault zur Vergügung. Das erleichtert einiges.
 
  • Like
  • Sad
Reaktionen: shivagnihotri, Uli und NoG....eFan
In Ordnung, ich schlucke den Schmerz herunter. Danke an dieser Stelle an alle Helferinnen und Helfer, an den Support, an Euch Entwickler und an alle, die hier mit guten Ideen und Energien beigetragen haben. Sollte Euch noch was einfallen - ich lese mit. Liebe Grüße aus Paraguay! 🇵🇾

//Nachtrag: Mein ganz besonderer Dank gilt @Lhotze für seine extreme Ausdauer und seine stabile Unterstützung via Telegram. DANKE! ❤️
 
Zuletzt bearbeitet:
  • Like
Reaktionen: Martin S., Uli und danielp
Lass mal hören ob du es mit einem "einfachen factory reset" dann auch tatsächlich zum Laufen bekommen hast. Gelernt haben wir alle ja sehr viel von deinem Rettungsversuch😁
 
Factory Reset hat schon vor zwei Tagen ohne Probleme funktioniert.
Auch ein Updaten oder Neueinrichten danach.

Erst beim Versuch des Rückspielens der Datenpartition via ADB gab es dann Probleme.
Fehlermeldungen im Bytcode.
Fastboot hat die Probleme umgangen und ein aufspielen erzwungen...
Beim Neustart war dann der alte Fehler wieder da und ein Systemupdate via Recovery oder ADB wurde auch Blockiert. Ein deutliches Zeichen, dass es diese Partitionel war.
Also:
Immer Backup und nie ein System beim Starten stören.
Da sind wir bei dem viel belächelten "USB sicher entfernen" Phänomen 😅.

Greetz
 
  • Like
Reaktionen: duckface, Uli, Martin S. und 2 andere
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben Unten