[AOSP/AOKP-KERNEL][ICS] *04.07.12* Fluxi XX.03-beta1[xxTweaker App, OTA, Touch CMWR]

[sav]

Auch hier Error 7 nach OTA Update -> kann nicht auf die neuste Nightly updaten.
Lösung: Sinyah drauf -> Reboot > CM9 nightly drauf -> bei bedarf Fluxi drauf, ich warte jetzt aber erstmal auf die nächste Version...

 

[Jake1]

Mal das UKCS probiert?

 

[sav]

Das hilft nicht. Das mach ich Grundsätzlich immer.
Vollständiges vorgehen war -> UKCS -> CM9 -> Error 7 -> Siyah -> Reboot -> UKCS -> CM9 -> reboot -> erstmal nix weiter.

 

[fluxi]

Ich hatte den "Status 7" Fehler gestern ebenfalls. Es ist allerdings garantiert kein Kernel-Issue, da derselbe Fehler mit einem alten Nandroid Image (XX.01) auftrat und auch mit CM9 stock, nach /data Wipe und auch nach /system Wipe. Fragt bei CM nach.

der xxtweaker meldet mir nach dem start immer

"Abweichende Exynos Sensor HAL, wiederhergestellt"

Logs, Logs, Logs...

 

[pro.aggro]

Hab es gerade getestet. Ich kann Roms flashen. Also keine Probleme mit dem Status 7 Error.

 

[sav]

Hab es grad extra nochmal Probiert.
CM9 Nightly mit CM9 Kernel installieren -> geht.
Siyah über CM9 Kernel -> CM9 Nightly flashen -> geht.
Älteren Fluxi drauf -> CM9 Nightly -> geht.
Älteren Fluxi drauf -> Boot -> OTA Update auf neuste Version -> Recovery -> Error 7 :/
Zwischendurch wurde natürlich immer mit reboot und UKCS gearbeitet. Seltsam.
Hab leider keine Ahnung wie sich sowas loggen lässt Fluxi, falls du ne Idee hast: las es mich wissen, ich schick dir gerne alles was benötigt wird.

 

[Rockystrike]

Also wenn ich eine Rom manuell flashen will bekomme ich den Fehler, dass er die build.prop scannt ob ich ein "GT-I9100" besitze und dies nicht korrekt findet und somit die Installation abbricht.
Wenn ich über xxTweaker flashe dann kommt einfach nur "Status 7 Error"
Dieses Problem habe ich mit der 11-06 Nightly.
Da es aber bei pro.aggro ohne Probleme klappt behaupte ich jetzt einfach mal, dass es ein CM9 Fehler ist.

 

[pro.aggro]

Ich muss dazu sagen, ich hab es mit der Paranoidv1.1.zip probiert. Ich saug mir mal eben die neuste Nighlty. Mit der habt ihr das Problem?

 

[sav]

Bei mir kam das Problem heute zum ersten mal beim Update der Nighly vom letzten Sa/So auf die heutige.

 

[ronnsen]

Ich saug mir mal eben die neuste Nighlty. Mit der habt ihr das Problem?

Scheint so

 

[sav]

@Fluxi
Was kann man sich eigentlich unter
"Kernel: mach-exynos: cpufreq: Entspricht Samsung i9300 Update 1" vorstellen? Was bringt es uns für Vorteile?

 

[Alex0901]

Also bei mir auch Status 7.

Fluxxi beta 1 geflashed, damit konnte ich auch das Nightly von heute flashen.

 

[Rockystrike]

12er Nightly macht auch Probleme.

Wie gesagt,

Opening update package ...

Failure get build.prop=GT-I9100

Wie genau es da steht weiß ich nicht mehr habe jetzt die *.tar von CM9 geflasht, dann 12er Nightly und direkt neusten Fluxi hinterher.
Ich probiere gleich nochmal den Flash einer ROM, ich glaube aber das der Fehler wieder auftaucht.

 

[pro.aggro]

Also mit der neusten Nightly kommt der Fehler auch bei mir. Liegt auch ganz sicher daran, weil andere Zips laufen!

 

[fluxi]

Das ist genau das Problem: Alle anderen Zips laufen. CM hat etwas geändert, und ich muss nun herausfinden, was es ist.

 

[sav]

Im CM9 Thread stand was von "Die aktuelle nightly 12 bricht bei mir mit einer falschen Produktinfo ab....Im CWM steht als Produktinfo GT-I9100T.....zum Glück hat er abgebrochen "
Eventuell hilft dir das @ Fluxi

 

[Rockystrike]

Ja ich weiß nicht ob alles einfach zu schnell runterläuft oder ob ich mich täusche aber ich meine auch das der nicht einfach bei "device=" nach GT-I9100 sucht sondern nur nach "I9100T" und "I9100P"

Keine Ahnung was das soll Ich hoffe mal, dass du den Fix schnell findest Fluxi. Nicht uns zuliebe sondern, dass dir einfach nicht zu viel Arbeit jetzt dadurch entsteht.

 

[sav]

Immerhin wär das schon mal eine gute Neuerung für eine Spätere Recovery Version: Scrollbare Textanzeigen, damit man auch mal nachvollziehen kann was die ganzen Skripte da für tollen Text schreiben

 

[MadMurdoc]

Postet den CWM Log.

/cache/recovery/last_log

Das könnte schon helfen.

------
Möge die Macht mit dir sein.
Versendet von meinem SGS2

 

[fluxi]

Der Workaround ist sehr einfach: /META-INF/com/google/android/updater-script mit einem UNIX tauglichen Editor (Ultra-Edit, PSPad, Notepad++) bearbeiten und den oberen Teil mit den zu prüfenden Properties löschen:

Weg hiermit:

assert(getprop("ro.product.device") == "galaxys2" || getprop("ro.build.product") == "galaxys2" || 
       getprop("ro.product.device") == "GT-I9100" || getprop("ro.build.product") == "GT-I9100" || 
       getprop("ro.product.device") == "GT-I9100M" || getprop("ro.build.product") == "GT-I9100M" || 
       getprop("ro.product.device") == "GT-I9100P" || getprop("ro.build.product") == "GT-I9100P" || 
       getprop("ro.product.device") == "GT-I9100T" || getprop("ro.build.product") == "GT-I9100T");

Alle last_logs sehen gleich aus, das hilft nicht. Die Lösung liegt im CM Prüfcode. Leider kann ich gerade hierfür keine Zeit aufwenden - sorry.