Recovery boot nicht möglich - ICS

[Ora]

Hallo Community,

Problem:
Weder mit Titanium noch über die Tastenkombination "Power & Volume down" lässt sich das TPT zum Recovery boot bewegen.

Was habe ich bisher unternommen:
- Einmal zu Testzwecken unter ICS mit Tastenkombination erfolgreich gestartet und mittel reboot beendet.
- Danach mit falscher Tasten-Kombination (Volume up) mehrer erfolglose Wiederholungsversuche.
- Danach mit richtiger Tasten-Kombination (Volume down) mehrer erfolglose Wiederholungsversuche.
-Aus Datensicherung install-recovery.sh und recovery-from-boot.p mit Stand nach ICS Upate zurück gespielt und mit su und der TE gestartet.
- Kein Erfolg, Weder mit Tasten noch mit Titanium
- Die Ausgabe des Scripts anbei

Welcher Spezi stellt sich dem Problem?

 

[Ora]

Ich würde mich auch freuen, wenn mal einer betätigt, dass bei seinem TPT das Recovery Menü erreichbar ist

 

[Xyl]

Geht ganz normal mit Volume Up.

Ich würde mich auch freuen, wenn mal einer betätigt, dass bei seinem TPT das Recovery Menü erreichbar ist

Ich hätte normal nichts dazu geschrieben denn für mich ist klar dass es nur ein vereinzeltes Problem sein kann denn sonst wären hier und auf XDA wieder eine Fülle von Post´s erschienen zu diesem Thema.

Was mir spontan zu deinem Problem in den Kopf geschossen ist war die Frage ob deine Lautstärkeknöpfe funktionieren?

 

[Ora]

Kann mal einer die md5sum von
/system/etc/install-recovery-boot.sh
/system/recovery-from-boot.p
im ICS posten

Der ursprüngliche Beitrag von 17:52 Uhr wurde um 17:57 Uhr ergänzt:

Geht ganz normal mit Volume Up.



Ich hätte normal nichts dazu geschrieben denn für mich ist klar dass es nur ein vereinzeltes Problem sein kann denn sonst wären hier und auf XDA wieder eine Fülle von Post´s erschienen zu diesem Thema.

Was mir spontan zu deinem Problem in den Kopf geschossen ist war die Frage ob deine Lautstärkeknöpfe funktionieren?

Ich schrieb, dass es auch mittels titanium Kommando nicht geht

 

[Ora]

Geht ganz normal mit Volume Up.



Ich hätte normal nichts dazu geschrieben denn für mich ist klar dass es nur ein vereinzeltes Problem sein kann denn sonst wären hier und auf XDA wieder eine Fülle von Post´s erschienen zu diesem Thema.

Was mir spontan zu deinem Problem in den Kopf geschossen ist war die Frage ob deine Lautstärkeknöpfe funktionieren?

Das Problem besteht auch nach dem letztem Patch. Dieser wechselte
/system/etc/install-recovery.sh
/system/recovery-from-boot.p
die werden zwar ausgepackt aber das script wird nicht gestartet. Bedeutet, der update versucht standardmäßig keine Erneuerung.


Es könnte sein, dass bei funktionierende Recovery boot die noch funktionieren p1 unnd p2 noch korrekt arbeiten.
1 mal konnte ich ja auch in das Menu. Danach aber nie wieder.

Der Aufruf des Install shell Scriptes bring aber für mich noch unverständliche Fehlermeldungen:

contents of partition "/dev/block/mmcblk0p1" didn't match EMMC:/dev/block/mmcblk0p1:4229120:8457510f46b6082c40ecfa9b0db879f82af00b7e
file "EMMC:/dev/block/mmcblk0p1:4229120:8457510f46b6082c40ecfa9b0db879f82af00b7e" doesn't have any of expected sha1 sums; checking cache
cache bits don't match any sha1 for "EMMC:/dev/block/mmcblk0p1:4229120:8457510f46b6082c40ecfa9b0db879f82af00b7e"

applying patch to EMMC:/dev/block/mmcblk0p2:3831808:8ae8182936495962516470453eda3a7146b9609d
LoadPartitionContents called with bad filename (EMMC:/dev/block/mmcblk0p1)
contents of partition "/dev/block/mmcblk0p1" didn't match EMMC:/dev/block/mmcblk0p1
contents of partition "/dev/block/mmcblk0p2" didn't match EMMC:/dev/block/mmcblk0p2:3831808:8ae8182936495962516470453eda3a7146b9609d
source file is bad; trying copy
copy file doesn't match source SHA-1s either

 

[jpmmuc]

Das Problem besteht auch nach dem letztem Patch. Dieser wechselte
/system/etc/install-recovery.sh
/system/recovery-from-boot.p
die werden zwar ausgepackt aber das script wird nicht gestartet.

Welchen Patch meinst Du genau, den aktuellen 130_WE?
Dort werden die Recovery Wiederherstellungsdateien ausgetauscht:

delete("/system/recovery-from-boot.p",
       "/system/etc/install-recovery.sh");
ui_print("Unpacking new recovery...");
package_extract_dir("recovery", "/system");

Der Aufruf des Install shell Scriptes bring aber für mich noch unverständliche Fehlermeldungen:

contents of partition "/dev/block/mmcblk0p1" didn't match EMMC:/dev/block/mmcblk0p1:4229120:8457510f46b6082c40ecfa9b0db879f82af00b7e
file "EMMC:/dev/block/mmcblk0p1:4229120:8457510f46b6082c40ecfa9b0db879f82af00b7e" doesn't have any of expected sha1 sums; checking cache
cache bits don't match any sha1 for "EMMC:/dev/block/mmcblk0p1:4229120:8457510f46b6082c40ecfa9b0db879f82af00b7e"

applying patch to EMMC:/dev/block/mmcblk0p2:3831808:8ae8182936495962516470453eda3a7146b9609d
LoadPartitionContents called with bad filename (EMMC:/dev/block/mmcblk0p1)
contents of partition "/dev/block/mmcblk0p1" didn't match EMMC:/dev/block/mmcblk0p1
contents of partition "/dev/block/mmcblk0p2" didn't match EMMC:/dev/block/mmcblk0p2:3831808:8ae8182936495962516470453eda3a7146b9609d
source file is bad; trying copy
copy file doesn't match source SHA-1s either

So wie ich das sehe stimmen die SHA-1 Checksums nicht mit den Werten im Patch überein und werden daher nicht ausgeführt.

Im 130_WE Script wird die noch das Bootimage gepatcht:

ui_print("Patching boot image...");
apply_patch("EMMC:/dev/block/mmcblk0p2:3831808:0bdad6c8b9c21e0674e64454afaa09b8183ef2be:3831808:c592a2b5ded8113a99ad5b03ef355bd213f1dd0a",
            "-", c592a2b5ded8113a99ad5b03ef355bd213f1dd0a, 3831808,
            0bdad6c8b9c21e0674e64454afaa09b8183ef2be, package_extract_file("patch/boot.img.p"));

Jpmmuc.

 

[Ora]

Ich meine den 130
Ich bin auch der Meinung, dass zwar die Sources gewechselt werden, auch das boot image erneuert wird (p2), nicht aber auch p1
Ich will ja nicht vermessen sein, hast Du Lust es mal zu testen?
Was 'ne falsche SHA1 bedeutet und welche dann falsch weiss ich noch nicht und gleich gar nicht wie man den Fehler behebt. Könnte man das block device neu erzeugen? Make node oder so ähnlich, Unix ist schon lange her,

mobil geantwortet
hier die md5sum's
md5sum /system/recovery-from-boot.p
9a2948d373cdde2a281913052cb8dc05 /system/recovery-from-boot.p
md5sum /system/etc/install-recovery.sh
4f7230c2b980fab4ea0398daea4b8b68 /system/etc/install-recovery.sh

und hier der aktuelle Stand dieser Partitionen:

##
dd if=/dev/block/mmcblk0p1 of=/data/local/mmcblk0p1.img
12288+0 records in
12288+0 records out
md5sum /data/local/mmcblk0p1.img
7715dc3ed65aaa0efe205087951c77aa  /data/local/mmcblk0p1.img
##
dd if=/dev/block/mmcblk0p2 of=/data/local/mmcblk0p2.img
16384+0 records in
16384+0 records out
md5sum /data/local/mmcblk0p2.img
02f19ea8602834ebc8f9da40fb4d6d19  /data/local/mmcblk0p2.img

Hilft vielleich das blockweise kopieren mit dd, natürlich voraussgesetzt man hat(bekommt) ein funktionsbereites img (vielleich Deins)

------------------------------
Asche auf mein Haupt Volume + und die nicht gleichzeitig, sondern nach dem Brummen mehrfach.

Kurios bleibt, die Fehlermeldungen des install-recovery.sh waren erst verschwunden, nachdem ich mit dd if=recovery-from-boot.p ein nicht image draufgezängt hatte.
Un das Boot Recovery enu vom Titanium is entwede ein völlig anderes Kommando ode funktioniert nicht.

 

[jpmmuc]

Asche auf mein Haupt Volume + und die nicht gleichzeitig, sondern nach dem Brummen mehrfach.

Kurios bleibt, die Fehlermeldungen des install-recovery.sh waren erst verschwunden, nachdem ich mit dd if=recovery-from-boot.p ein nicht image draufgezängt hatte.
Un das Boot Recovery enu vom Titanium is entwede ein völlig anderes Kommando ode funktioniert nicht.

Zu Punkt 1, ich bin automatisch davon ausgegangen, dass es nicht am DAU Faktor liegt

Zu Punkt 2, die Fehlermeldung ist in der Tat merkwürdig.
Logisch ist für mich hingegen, dass wenn Du P1 mit falschem Inhalt füllst, dass es dann neu geschrieben wird. Allerdings hat hier im Forum auch schon jemand das Thema, dass er P1 so wie Du überschrieben hat, allerdings nicht mehr in's Tablet kommt um P1 neu zu schreiben.

Zu Punkt 3, bzgl. Titanium habe ich die Meinung, dass es für Backups in der Systemumgebung nicht funktioniert und verwende es deshalb nicht mehr.

Ich kann Deine md5's nicht vergleichen, da ich das 130er Update nicht gemacht habe. Vor allem finde ich es merkwürdig, dass es neue Inhalte für Recovery gibt, aber dies nicht durchgeführt wird ...

Jpmmuc

 

[Ora]

Zu Punkt 2, die Fehlermeldung ist in der Tat merkwürdig.
Logisch ist für mich hingegen, dass wenn Du P1 mit falschem Inhalt füllst, dass es dann neu geschrieben wird. Allerdings hat hier im Forum auch schon jemand das Thema, dass er P1 so wie Du überschrieben hat, allerdings nicht mehr in's Tablet kommt um P1 neu zu schreiben.

Ich kann Deine md5's nicht vergleichen, da ich das 130er Update nicht gemacht habe. Vor allem finde ich es merkwürdig, dass es neue Inhalte für Recovery gibt, aber dies nicht durchgeführt wird ...

Jpmmuc

Es liegt die Vermutung nah, dass die P1 vor dem dd in einem Zustand war, dass applypatch kein "Erneuern" schafft. Dieser Zustand aber durch dd selbst mit einem sinnlosen of="binär file" den Zustand soweit verändert, dass applypach beim check feststellt "kein aktueller Inhalt" und diesen dann wie vorgesehen tauscht. Denn der sha 1 status Fehler wird dabei nicht mehr als return code reportet.
Und solange man nicht dann den falschen P1 Inhalt zum Recovery boot nutz, bleibt ja alles unbemerkt. (Davor bewarte mich übrigens 1.)
Das übrigens ist der Fehlergrund mancher hier berichteter boot loops. Wichtig war, dass man sofort nach dem dd oder spätestens vor dem Recovery-boot Versuch das applypatch richtig parametrisiert (also /system/etc/install-recovery startet und das auf dem TPT selbst.

Es hat mir Spass gemacht, mit Dir so fachkundig nach der Fehlerursache zu suchen.

 

[jpmmuc]

Es liegt die Vermutung nah, dass die P1 vor dem dd in einem Zustand war, dass applypatch kein "Erneuern" schafft.

Wichtig war, dass man sofort nach dem dd oder spätestens vor dem Recovery-boot Versuch das applypatch richtig parametrisiert (also /system/etc/install-recovery startet und das auf dem TPT selbst.

Dass applypatch nicht funktioniert hat, kann ich nicht nachvollziehen ...

Tatsächlich scheint es so zu sein, dass ohne korrektes P1 das Tablet in Probleme kommt, insofern ist der von Dir genannte Punkt wohl wesentlich.

Ich habe mir nochmal das alte (126_WE) Updater Script angesehen, dort wird das install-recovery auch nicht gestartet, wahrscheinlich wird das erst beim ersten Reboot oder sogar erst bei Bedarf, sprich beim Aufruf der Recovery Konsole gestartet.
Sollte diese Annahme korrekt sein, ist es klar, dass das Tablet in einer Loop hängt. 1. Recovery Konsole kann nicht gestartet werden, da das boot Image geändert wurde. 2. Das Recovery Image kann nicht aktualisiert werden, da applypatch auf einen Fehler läuft.

Also, wäre es wohl wichtig zu wissen, warum oder besser unter welchen Umständen applypatch nicht funktioniert ...

Jpmmuc