[RECOVERY][KLTE] *20.05.2019* TWRP 3.3.1-0 Touch Recovery

[joe-F5]

@fipsy, @fireburner, @Xavier, @Nufan ,

Nach Neuinstallation(OS) hat alles geklappt mit TWRP3.2.0.0!!!

Vielen Dank EUCH ALLEN

 

[fipsy]

Na, das ist ja sehr erfreulich! Aber mir ist immer noch nicht klar, wo die Ursache des Problems lag. Denn eine Installation des OS hat ja keine Auswirkung auf die Recovery. Außer wenn zusammen mit dem OS eine Recovery installiert wird. Aber auch dann erscheint es mir seltsam. Kann sich das jemand erklären?

 

[corvuscorax]

Die Tools erkennen das Gerät bei laufendem Android über ADB. Für Flashvorgänge ist ein Reboot in den Fastboot Mode nötig und dann muss Windows das Gerät neu erkennen und andere Treiber installieren. Wenn das nicht klappt, passiert oft gar nichts mehr, keine Fehlermeldung, kein Abbruch.

 

[fipsy]

Soweit ich das verstanden habe, wurde das Gerät im Downloadmodus von Odin aber stets korrekt erkannt. Daher würde ich davon ausgehen, dass die Windows-Treiber immer richtig liefen. Wir werden der Ursache des Problems wohl nicht auf die Schliche kommen...

 

[corvuscorax]

Im ersten Anlauf, ja.
Dann kommt unweigerlich der Reboot-Befehl. Ich habe das schon über Konsole gemacht, was auch ne Möglichkeit ist. Bei nem Konsolen-Tool sind dann auch wieder neue Treiber bei. Bei meinem Problemgerät damals hat das aber auch nicht geholfen. Es lag wohl an der seit 2012/13 nicht mehr supporteten TI OMAP Family, kam auch im S2 zum Einsatz.
Möglicherweise hat sogar Samsung die Rechte an Mobil-SoCs von TI übernommen und die Hausmarke-Chips sind Weiterentwicklungen davon. Und hier könnte ein S5 mit Samsung - SoC wie das Neo vorliegen, dann schließt sich der Kreis sogar...

 

[fipsy]

Das heißt, der Flash-Vorgang wird in Odin korrekt und ohne Fehlermeldung abgeschlossen, aber trotzdem ist er nicht erfolgreich?

Wenn es ein Problem mit der Hardware ist, so wie du es beschrieben hast, ist es aber auch wieder seltsam, dass nach dem erneuten Flashen eines kompletten Stock-ROMs, das Flashen der Custom Recovery plötzlich wunderbar funktioniert. Klingt für mich dann auch unlogisch, denn die Hardware wird dadurch ja nicht verändert.

 

[joe-F5]

Hallo zusammen,

habe ein seltsames verhalten mit TWRP.3.2.0.0
- ich habe erfolgreich ein Backup auf die SD-Karte gemacht (Backup compled)
- dann wollte ich ein Restore vom gleichen Backup machen(zum überprüfen ob alles klappt)
geht nicht!! fängt nach Auswahl vom Backup( vom vorherigen Backup) an, danach
passert nichts mehr (sehe keinen Fortschritt oder sonstige Nachricht) nach 10 Min. abgebrochen,
weil Akku heiß wurde.

Power off/Power on System bootet mit lineage-14.1-20171214-nightly.
BL=BL_G900FXXS1CQI6.tar
CP=CP_G900FXXU1CQC2.tar.

Danke für Antwort.

 

[fipsy]

@joe-F5: Wie sieht es mit TWRP 3.2.1.0 aus? Eventuell wurde der Fehler dort behoben. Aber vielen Dank für diese Info! Wenn ein Backup nicht wiederherstellbar ist, ist das ja der maximal anzunehmende Unfall! Das macht den Nutzen einer solchen Recovery völlig zunichte.

 

[Nufan]

Das ist wohl war, aber da besteht ja noch die Möglichkeit des Versuchs der Wiederherstellung mit einem bekannterweise funktionierenden Recovery.
Wenn schon die Sicherung schieflief, wirds natürlich Brühe..

 

[submain]

Deshalb sollte man immer die Option zur Überprüfung des Backups aktivieren... Dann dauert zwar das Backup länger, aber man kann von vornherein ein neues Backup machen, wenn das erste fehlerhaft ist.

Manchmal hat auch die SD Karte defekte Sektoren... Und dann hängt es irgendwo bei der Wiederherstellung fest

 

[fipsy]

Aber die Überprüfung ist meines Wissens nur vor der Wiederherstellung möglich, nicht direkt nach dem Backup, wie man das sonst bei Backupsystemen gewohnt ist. Allerdings ist die Erzeugung der MD5 Checksum ja zumindest schon sowas wie eine Überprüfung des Datenträgers. Wenn da was faul ist, sollte die Erzeugung der Checksum fehlschlagen (hoffe ich doch!). Vielleicht kann @joe-F5 uns ja noch sagen, ob er die MD5-Überprüfung aktiviert hatte?! Danke!

 

[Nufan]

Die bei der Sicherung erzeugte md5 wird erst vor der Wiederherstellung überprüft , wenn die nicht stimmt gibt es eine Fehlermeldung in Form eines schönen roten Schriftzuges und Abbruch.
Der Log müßte ja einiges aussagen, aber

fängt nach Auswahl vom Backup( vom vorherigen Backup) an, danach
passert nichts mehr (sehe keinen Fortschritt oder sonstige Nachricht) nach 10 Min. abgebrochen,
weil Akku heiß wurde

läßt vermuten, das Gerät hat sich einfach direkt aufgehängt.
Da könnte ich mir auch defekte Sektoren auf der Karte zB als Ursache vorstellen.

 

[fipsy]

Bleibt noch die Frage was passiert, wenn vor der Wiederherstellung die Checksum überprüft wird und dabei ein Lese-Fehler auftritt. Wenn Sektorfehler beim Lesen auftreten, sollte das Teil ja eigentlich nicht 10 Minuten hängenbleiben, sondern sich irgendwann mit Timeout zurückmelden. Hängt natürlich davon ab, wie viele Leseversuche stattfinden, wenn ein Sektor nicht gelesen werden kann. Aber 10 Minuten kommen mir doch schon ziemlich komisch vor.

 

[Nufan]

Keine Meldung im Log heißt auch keine Aktion, wer weiß, ob das Gerät überhaupt soweit kam, bevor es einfror.

fängt nach Auswahl vom Backup( vom vorherigen Backup) an,

wie meinst du das, hast du die Wiederherstellung denn noch starten können?

 

[corvuscorax]

Beim S5 hatte ich noch gar kein Restore nötig, Backups mache ich aber trotzdem.
Anders bei meinem Note.
Bei Samsung werden anders als bei Anderen EFS(Partitionstabelle?) und Modem/Baseband mitgesichert. Beim Restore des Modems bleibt Twrp beim P605 hängen, und zwar das Offizielle und ein Weiteres. Das Modem wird ganz zum Schluss restored, man kann dann Reset machen, immerhin hängt es nicht nach dem Löschen, sondern vorher oder nach dem Überschreiben. Oder Modem beim Restore abwählen, dann sollte es sauber abschließen.
Solange das OS noch läuft, kann es auch nen Unterschied machen ob man Twrp beim Einschalten oder per Reboot to Recovery aufruft.

 

[joe-F5]

@fipsy und alle andern !!

Ich habe beim twrp3.2.0.0 beim backup die Meldungen "digest.." bekommen und backup compled", also war die Überprüfung an.Oder?
Jetzt habe ich die akt. Vers.Twrp-3.2.1-0-klte.img.tar installiert mit Odin
und unter Settings "Zip Signatue verification,Enable Digest verification.." angehakt, danach erfolgreich ein Backup gemacht"Backup compled"

Ein Restore habe ich noch nicht gemacht... bin mir unsicher was passiert wenn es dabei zu Fehler kommt

Wollte mal auf Antwort von euch warten.

 

[corvuscorax]

Die Zip Verification verhindert das Flashen der meisten Zips, weil die meist nicht verifiziert sind.
Digest sind die MD5 Checksums beim Backup. Ich hatte noch nie Datenkorruption beim Restore, wenn man das weg läßt spart das massig Zeit.

 

[fipsy]

Ich hatte auch noch nie ein fehlerhaftes Restore, trotzdem erzeuge ich aber Prüfsummen, weil die Daten über das Netzwerk auf das NAS kopiert werden. Da ist das schon sinnvoll. Warum wurde das MD5 eigentlich in Digest umbenannt? Das impliziert, dass die Prüfsummen jetzt anders erstellt oder verarbeitet werden als früher. Ich dachte, dass die Probleme vielleicht daher kommen könnten.

 

[corvuscorax]

Da sollte es auch keine Fehler geben, ws sei denn die Verbindung bricht ab.
Kürzlich gehabt beim Note oder S5. Es lag eindeutig am Akkustand um fünf Prozent und damit niedriger "Bordspannung", da ging es um nen FTP-Copyjob.

 

[fipsy]

@corvuscorax: Leider sind Netzwerkkomponenten nicht immer so zuverlässig, wie man hofft. Beim Kopieren über das Netzwerk können sich leider auch Fehler einschleichen. Ich habe einen Managed Gigabit Switch von Netgear, der nicht ganz billig war. Irgendwann waren plötzlich viele größere Dateien nach dem Kopieren über diesen Switch verhunzt. Der Switch zeigte zwar auch interne CRC-Fehler, diese hatten aber keine Auswirkung auf den Kopiervorgang, der fehlerfrei durchlief - mit kaputter Datei. Nach dem Reboot des Switches war alles wieder okay. Weder davor noch danach ist der Fehler jemals wieder aufgetreten. Daher würde ich jeder über ein Netzwerk kopierten, größeren Datei stets misstrauen. Besonders, wenn sie sehr wichtige Daten enthält. Ich hatte schon immer wieder mal in meinem Leben Netzwerkfehler. Daher gibt's bei wichtigen Sachen bei mir immer eine MD5.