TOUCH Recovery / Status 7 Fehler

    Guten Tag liebe Forengemeinde,


    Immer mehr kommt es vor, dass User von diesem Status 7 Problem berichten. Dieser Fehler liegt am Recovery. Mit dem Touch Recovery scheint es bis dato nicht möglich zu sein MIUI zu flashen. Wo genau der Fehler liegt weiss ich nicht. Die einzige Möglichkeit die ihr habt ist den CF-Root von hier mit ODIN Bei PDA zu flashen. Danach sollte es ohne Probleme funktionieren. Es gäbe da noch eine weitere Möglichkeit, nämlich den Updater Script zu bearbeiten, doch wer das machen will, soll das selber Googeln. Danach wird nicht mehr geprüft ob es sich um das richtige Gerät handelt. Wenn ihr dann also etwas falsches flasht, kann das böse enden.


    Gruss,
    hells

    Keine Ahnung obs da einen Fix geben wird. Wenn man MIUI flashen möchte, bleibt einem wohl nichts anderes übrig... Ich hätte auch lieber das Touch Recovery, aber was will man machen...


    hells

    Der Fehler lieg in dem Umstand, dass das getprop Kommando beim offiziellen CWM 6 andere Werte liefert als in der build.prop hinterlegt sind.
    Auch ein setprop auf die richtigen Werte hatte bei meinen Versuchen keinen Effekt.

    Habe nach vielen vergeblichen Versuchen die Anleitung entdecht. Wie durch ein Wunder: mit CF-Root hat das August Update geklappt.


    Alle neuen Updates funktionieren aber trotz CR-Root nicht - bringen eine Fehlermeldung. Bin ich der einzige der dieses Problem hat? CF-Root habe ich schon neu installiert. Was kann ich noch tun?

    Was für eine Fehlermeldung?


    Um MIUI auch mit Touch Recovery zu flashen, muss man einfach den Updater Script bearbeiten. Es wurde früher schon einmal erwähnt, ich erwähne es nur noch einmal. Ladet einfach Notepad++ runter, geht in die .zip unter META-INF/com/google/androud/updater-script und entfern folgende Zeilen:


    "assert(getprop("ro.product.device") == "m0" ||
    getprop("ro.build.product") == "m0" || getprop("ro.product.device") == "galaxys3" || getprop("ro.build.product") == "galaxys3");"


    Das Touch Recovery prüft die build.prop anders, darum kommt es zum Status 7 Fehler. Wir können das in den wöchentlichen Updates nicht so ändern, da KEINE Deviceüberprüfung mehr stattfindet, und das Gerät BRICKEN kann, wenn man eine falsche ROM geladen hat.


    hells

    Quote

    Die Fehlermeldung lautet immer
    cant open ..... (bad) Installation aborted.

    Zusätzlich sollte der Signaturcheck in der Recovery ausgeschaltet sein, da mit bearbeiten der updater-script.sh sich auch die signatur ändert. Weiß nicht ob die standardmäßig aus ist.
    Das TouchRecovery prüft auf jeden fall nicht die /system/build.prop und auch nicht die /default.prop. An beiden Dateien habe ich Änderungen vorgenommen die nicht erkannt wurden.


    Auch das manuelle setzen der richtigen Werte mit setprop ändert nichts. Ich ~vermute~ daher, dass die modellnummer hardcoded ist. Was auch Sinn machen würde, denn die cwm touch ist ja praktisch auch nur für unser device.
    Um das nachzuprüfen müsste ich die recovery einfach mal unpacken.


    Zum Bricken:
    Durch das Script wird nur die /system partition geflashed. Solang man ein Nandroid Backup hat kann man die vorherige Version zurückspielen.
    So sehr "bricken", dass am ende kein Download Mode mehr verfügbar ist kann man (zumindest mit den offiziellen MIUI packages) nicht.
    Dafür müsste man dem updater-script schon sagen es solle alle partitionen weghauen. (wichtig is hier die param partition die u.A. auch die bildchen im download modus enthält sowie andere zur bootzeit benötigten elemente)


    ok, war jetzt weit ausgeholt, aber viell. interessierts ja wen :D

    Es wirds ja auch ein Kernel mitgeflasht mit der ROM. Und das kann böse enden. Es ist also nicht nur die /system Partition ;)


    hells

    Keine Sorge, auch beim Kernel kann es noch gar nicht böse enden. Klar, ist ein falscher/korrupter Kernel da, oder ist die /boot partition gar leer, kommt das Gerät nicht über den Bootscreen hinaus. Aber als Faustregel: Solange du in den Download Mode kommst ist nichts verloren.


    Ich empfehle jedem nach Installation der Recovery ein NANDROID backup, sowie das Sichern der EFS Partition. Hat man beides ist man gegen die meisten DInge gefeit.
    Generell gilt: /system, /userdata, /boot, /recovery sind partitionen die selbst komplett gelöscht nicht schlimm sind.


    Schlimmer wird es, wenn low level komponenten fehlen wie zB. PBL, SBL (Primary und Secondary Bootloader). Diese Dinge werden noch vor dem "normalen booten" ausgeführt.
    Diese Komponenten kannst du dir wie das BIOS vorstellen. Sie initialisieren die Hardware etc.


    Diese Low Level Programme sind in der Regel auch nicht "gemapped" (sind nicht als mmcblk device verfügbar) und man kann diese speicherbereiche nicht zugreifen, es sei denn man schreibt selbst ein systemprogramm mit C und spricht die adressen direkt an.

    Ich denke zwar eher dass es an der 6.0.1.2 an sich und nicht am Touch liegt, aber probiers.


    edit: Ich hab mir die Arbeit mit dem Recovery erspart und nutze weiterhin das Touch. Ich lösche einfach folgende Zeilen aus dem Updater-Script der Zip raus:


    "assert(getprop("ro.product.device") == "m0" ||
    getprop("ro.build.product") == "m0" || getprop("ro.product.device") == "galaxys3" || getprop("ro.build.product") == "galaxys3");"


    hells

    Mobile Odin. Oder machs wie ich, oben beschrieben, die zwei Zeilen aus dem Updater Script löschen. Dann kannst auch dein Touch Recovery weiter nutzen.


    hells

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login