1. Nimm jetzt an unserem Uhans - 3. ADVENT - Gewinnspiel teil - Alle Informationen findest Du hier!

Recovery boot nicht möglich - ICS

Dieses Thema im Forum "Lenovo ThinkPad Tablet Forum" wurde erstellt von Ora, 26.06.2012.

  1. Ora, 26.06.2012 #1
    Ora

    Ora Threadstarter Marketing-Assistent Team-Mitglied

    Beiträge:
    4,697
    Erhaltene Danke:
    1,971
    Registriert seit:
    06.04.2012
    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?
     

    Anhänge:

  2. Ora, 29.06.2012 #2
    Ora

    Ora Threadstarter Marketing-Assistent Team-Mitglied

    Beiträge:
    4,697
    Erhaltene Danke:
    1,971
    Registriert seit:
    06.04.2012
    Ich würde mich auch freuen, wenn mal einer betätigt, dass bei seinem TPT das Recovery Menü erreichbar ist:smile:
     
  3. Xyl, 29.06.2012 #3
    Xyl

    Xyl Android-Hilfe.de Mitglied

    Beiträge:
    115
    Erhaltene Danke:
    17
    Registriert seit:
    25.10.2011
    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? :flapper:
     
  4. Ora, 29.06.2012 #4
    Ora

    Ora Threadstarter Marketing-Assistent Team-Mitglied

    Beiträge:
    4,697
    Erhaltene Danke:
    1,971
    Registriert seit:
    06.04.2012
    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:

    Ich schrieb, dass es auch mittels titanium Kommando nicht geht:(
     
    Zuletzt bearbeitet: 29.06.2012
  5. Ora, 01.07.2012 #5
    Ora

    Ora Threadstarter Marketing-Assistent Team-Mitglied

    Beiträge:
    4,697
    Erhaltene Danke:
    1,971
    Registriert seit:
    06.04.2012
    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:
    Code:
    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
    
     
    Zuletzt bearbeitet: 01.07.2012
  6. jpmmuc, 03.07.2012 #6
    jpmmuc

    jpmmuc Erfahrener Benutzer

    Beiträge:
    219
    Erhaltene Danke:
    54
    Registriert seit:
    11.08.2011
    Welchen Patch meinst Du genau, den aktuellen 130_WE?
    Dort werden die Recovery Wiederherstellungsdateien ausgetauscht:
    Code:
    delete("/system/recovery-from-boot.p",
           "/system/etc/install-recovery.sh");
    ui_print("Unpacking new recovery...");
    package_extract_dir("recovery", "/system");
    
    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:
    Code:
    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.
     
  7. Ora, 03.07.2012 #7
    Ora

    Ora Threadstarter Marketing-Assistent Team-Mitglied

    Beiträge:
    4,697
    Erhaltene Danke:
    1,971
    Registriert seit:
    06.04.2012
    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:

    Code:
    ##
    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.
    :thumbsup::thumbsup::thumbsup::thumbsup::thumbsup::thumbsup::thumbsup::thumbsup:
     
    Zuletzt bearbeitet: 03.07.2012
  8. jpmmuc, 04.07.2012 #8
    jpmmuc

    jpmmuc Erfahrener Benutzer

    Beiträge:
    219
    Erhaltene Danke:
    54
    Registriert seit:
    11.08.2011
    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
     
  9. Ora, 04.07.2012 #9
    Ora

    Ora Threadstarter Marketing-Assistent Team-Mitglied

    Beiträge:
    4,697
    Erhaltene Danke:
    1,971
    Registriert seit:
    06.04.2012
    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.:flapper:)
    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.:rolleyes2:
     
  10. jpmmuc, 05.07.2012 #10
    jpmmuc

    jpmmuc Erfahrener Benutzer

    Beiträge:
    219
    Erhaltene Danke:
    54
    Registriert seit:
    11.08.2011
    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
     
    Zuletzt bearbeitet: 05.07.2012

Diese Seite empfehlen

Besucher kamen mit folgenden Begriffen auf unsere Seite:

  1. recovery from boot.p