Chainfire-Tool [Got Brickbug] gefährdeter eMMC Chip

Thoddü;3413408 schrieb:

Sowie ich das mitbekommen habe, war der Fehler nur beim RC6 des Siyah-Kernels vorhanden, wurde seitdem aber längst gefixt. Wer also einen neueren Kernel hat, dürfte keine Probleme haben.

Kernel, die auf dem Siyah basieren, dürften dann aber natürlich auch betroffen sein, sofern sie auf RC6 basieren.

Gut, das ich noch immer auf Gingerbread fahre

Zum Vergrößern anklicken....

Nein, es betrifft generell ALLE ICS-Kernel. Um genauer zu sein, hat das sogar recht wenig mit dem Kernel zu tun, um nicht zu sagen : gar nichts.
Ich versuche mal das xda-Resumee (Discussion thread for /data EMMC lockup/corruption bug - Page 43 - xda-developers) zu resumieren :

1. Das Problem wird durch die Funktion "make_ext4fs()" ausgelöst. Sie gehört NICHT zum Kernel, sondern zu einer externen Bibliothek (Programmbibliothek), die "libext4_utils.a", die beim Kompilieren des Recoverys benutzt wird.
2. Diese Funktion wird sowohl bei einem wipe/factory reset als auch beim restoren eines Backups im Recovery-Menü benutzt.
3. Dieser Bug tritt erst seit ICS auf, da die Funktion in ihrer Art geändert wurde - in GB hat diese Funktion nicht versucht, die Partition zu formatieren bevor das Dateisystem (EXT4) erstellt wurde, es geht also speziell um die Funktion format(). Unter ICS ist das allerdings der Fall. Dies wiederum kann den eMMC superbrick bug auslösen. Das kann bei einer GB-Basis gar nicht erst passieren, da der Aufruf geblockt wird.
4. Der Bug tritt beim Shiften (Bitweiser Operator) auf. Daher ist es mehr oder weniger Zufall, wann der Bug auftritt.
5. Das Recovery an sich kann bombensicher gemacht werden, indem man auf eine GB-Basis aufbaut. In dieser ist ja der potentielle Bugauslöser nicht enthalten.
6. Jedoch ist dies nicht die einzige Quelle : Bei einem Update- bzw Flashvorgang via Recovery (install update.zip bzw install zip from sd card) wird die update-binary, eine Art Helferapp, aufgerufen (wer sich einen Kernel mal angeschaut hat, der findet das meist unter META-INF/com/google/android/). Bei diesem Flashvorgang wird vom Recovery aus eigentlich nichts gemacht ; das wichtigste übernimmt eben diese Helferapp. Sie ruft unter anderem auch diese Funktion auf, die den Bug auslösen kann. Auch hier gilt : Baut man das edify script (update-binary + updater-script) auf GB-Basis auf, dann ist es auch bombensicher.

Also Fazit: (hier ausnahmsweise den Wortlaut, da das wichtig ist)

So how do you make sure you are totally safe?
1) make sure you are using a "safe" recovery repacked with the stock ICS kernel. This is a Recovery that was compiled against GB-based libext4_utils.a (ie GB source) This will assure you that wipe data/factory reset and nandroid restores are safe
2) whenever you install a ROM for the first time, verify EITHER
a) the ROM install script is NOT performing any format() calls
b) the ROM install has bundled a GB-based update-binary

Zum Vergrößern anklicken....

1) Stellt sicher, dass euer Recovery auf einer GB-Basis gebaut wurde
2) Wenn ihr eine Rom das erste mal flasht, stellt sicher, dass

a) das edify script keine format()-Methoden aufruft
b) es auf einer GB-Basis gebaut wurde.


Anmerkung : Das ganze ist auf code tracing entstanden, d.h. es lagen zum Zeitpunkt des Posts noch keine RL-Resultate vor. Das ganze klingt aber dahingehend plausibel, als dass der Bug in der Form von einem offiziellen Android Dev letztens schon bestätigt wurde.

@MadMurdoc : Das ist kein hardwareseitiger Fehler. Der besagte Android Dev hat auch schon an einem Fix gearbeitet.

Möchte mich auch nochmal zum Thema melden, da gestern nicht mehr möglich.
Der Hinweis zum Programm diente nur zur Info.
Sicher interessiert den Fehler heute Keinen mehr, aber der Eine oder Andere wird halt beruhigt sein, nochmal mit dem Leben davon gekommen zu sein.
Ich bin z.B. froh, damals nicht gleich diese Version geflasht zu haben und ausserdem ist man ja doch neugierig, was in seinem Gerät so steckt.
Wen's nicht interessiert, der muss weder das Programm installieren, noch dessen Sinn kritisieren.
Da gibt es ganz andere unnütze Tools

Also wenn ich das jetzt richtig verstanden habe fährt man mit einem GB Recovery sicher?

Kann mir Jemand sagen wie ich das Recovery aus dem Fluxi GB Kernel extrahiere und auf einem beliebigen anderen Kernel flashe?


ps: Ich habe einen 0x19 Chip

@ trayzor

Danke für die Arbeit das zusammenzufassen und zu übersetzen!
Das bringt wenigstens etwas Licht ins Dunkel.

Christopher

Möchte mich dem anschließen, aber verbunden mit der Frage was ist nun zu tun?

Wenn dem wirklich so ist, wie in dem Post von XDA beschrieben, wäre ja die Möglichkeit das es wieder zu einem Brick kommt durchaus gegeben.

Das sehe ich leider genauso!

Mich würde deshalb auch interresieren ob der CF-Root Kernel, bzw das CWM Recovery was da mit kommt nun GB based oder ICS based ist.
Chainfire baut den Kernel ja nicht neu sondern 'patched' in nur.
Bis ich da nicht genaues drüber weis werde ich nicht über das CWM Recovery wipen.

Da es ja nicht bekannt ist welche offizielle Kernel Versionen da einen Bugfix haben und wenn sie einen haben dann dieser auch funktioinert, kann man meiner Meinung nach definitiv nicht ausschliessen das es unter ICS zu so einem Brick kommt.

Ein offizielles Statement von Samsung wird es da, wenn überhaupt, in absehbarer Zeit nicht geben.

MFG
Christopher

Wofür auch? Statements gibt es nur für Sachen, die den Normalverbraucher interessieren.

Aber eigentlich ist es schon ein Problem des Kernels, da dieser ja das Recovery mitbringt. Nur leider gibt es keiner Beschreibung eines ROMs oder Kernels einen Hinweis auf dieses Problem...

Gesendet von meinem GT-I9100 mit der Android-Hilfe.de App

.

Die zimage enthält doch den ganzen Kernel und nicht nur Recovery.

Das zImage enthälz ein RecoverY?

Schon mal in eine update.zip eines custom Kernels geschaut? Darin befindet sich idr neben dem update Skript und Binary nur das Zimage, und da bei jedem custom Kernel ein Recovery dabei ist muss dies mit in der Zimage Datei sein.

Cyanoid schrieb:

Die zimage enthält doch den ganzen Kernel und nicht nur Recovery.

Zum Vergrößern anklicken....

finnq schrieb:

Das zImage enthälz ein RecoverY?

Zum Vergrößern anklicken....

Cyanoid schrieb:

Schon mal in eine update.zip eines custom Kernels geschaut? Darin befindet sich idr neben dem update Skript und Binary nur das Zimage, und da bei jedem custom Kernel ein Recovery dabei ist muss dies mit in der Zimage Datei sein.

Zum Vergrößern anklicken....

Cyanoid,

du hattest Recht...eben gerade noch mal probiert...sorry, für die Falschmeldung ...habe mein Posting auch schon editiert...in der zImage ist sowohl der Kernel als auch die Recovery implementiert...

Ist das immer so?

Ja...zImage flasht sich in die Boot-Partition, wo der Bootloader und Kernel installiert werden...

Achso mist, ich habe das mit boot.img und recovery.img verwechselt. Die verwachsen ja aber im zImage..

Da war auch mein Gedankenfehler...

Und was sollen wir bitte tun um es beheben zu können ? Sofern es möglich ist

Von CM9 getapaltk

Nichts, außer darauf hoffen das dieses Problem allen Kernel Köchen bekannt ist. Ist halt nen Hardwareproblem, welches keinen Garantiefall ausläst.

Kjetal schrieb:

Schwachsinn ist es nicht Es besagt lediglich das in den besagten Geräten der Besagte chip ist welcher anfällig ist was nicht automatisch heist das das Gerät auch gebrigt wird.. Das mit dem Chip ist leider Fakt und das nicht erst seit gestern.

Gesendet von meinem GT-I9300

Zum Vergrößern anklicken....

@ mecss

Es zeugt von Charakter, seine eigenen Fehler öffentlich zuzugeben.
Fehler macht jeder, das macht uns menschlich.
Dafür mein Danke in deinem letzten Beitrag.

CU

Jetzt gehn wir mal davon aus mein phone ist gebrickt wegen diesem Fehler - dann kann ich es doch immer noch auf Kies schieben oder?

Sent from my GT-I9100 using Tapatalk 2

Naja ich denk mal theoretisch schon. Weil es dabei ja auch passieren könnte.
Aber ich mach mich da jetzt nicht so verrückt. Ich nehme es zur Kenntnis und gut. Momentan ist das ja nur bei der einen siyah version aufgetreten (oder sind noch andere fälle bekannt?)

Lg