Einleitung

Wie es bereits bekannt ist, existiert in den Samsung Stock-ICS 4.0.4 Rom wieder der Superbrick-Bug, der bei Wipe-Operationen in der Recovery den interen Flashspeicher zerschießt und aus dem S2 einen Briefbeschwerer macht.
Bisher war es für den normalen User nicht möglich zu erkennen, ob der Kernel eines neuen ICS-Releases den Bug besitzt, ohne sein Handy danach zum Service-Center schicken zu müssen. Grundsätzlich wird und wurde bei jedem neuen Release angenommen, dass dieser Brick-gefährdet ist.
Tungstwenty bei XDA hat eine Methode gefunden, den Kernel völlig gefahrenlos auf den Brick-Bug zu testen und den betroffenen MMC_CAP_ERASE Befehl zu deaktivieren.

Erkennen des Bugs

Jeder Kernel mit aktivierten MMC_CAP_ERASE löst den Brick-Bug aus. Zur Erkennung des Bugs muss also erkannt werden, ob dies bei dem zu untersuchenden Kernel der Fall ist.

Voraussetzungen:

Linux
oder
Windows mit Cygwin
Tungstwentys Script
Kernel als zImage

Durchführung:

Zur Untersuchung des Kernels das Script ausführen und den Kernel-Namen als Argument einfügen.
Bei Windows und Cygwin empfehle ich, sowohl das Script als auch den Kernel per Drag&Drop in das Cygwin Terminal Fenster zu schieben. Dabei auch darauf achten, dass beim Kernel-Pfad keine Leerzeichen vorhanden sind (dies hatte bei mir Probleme bereitet).
Auf einem Ubuntu 12.04 32-Bit musste ich vor Verwendung des Scriptes erstmal die Berechtigungen neu setzen, da es sonst immer zu einem Abbruch kam. Danach sollte es egal sein, ob man das Script als root oder Standard-User ausführt.

Beispiel Output des Scripts:

XWLPI-Kernel


XWLPO-Kernel:


Mehr Beispiele findet ihr im originalen XDA-Thread

Wie ihr seht, wird bei gefundenen Fehler auch noch angegeben, wo MMC_CAP_ERASE Code sich befindet und wie man ihn ändern muss um den Bug zu verhindern.

Beheben des Bugs

Voraussetzungen:
* Externes Kernel Unpack/Repack Script (Zu finden bei XDA)
* Linux box
* einen Hex-Editor
* Weitere, vom Kernel-Script vorausgesetzte, Dateien

1. Extrahiert mit dem Unpack/Repack Script die zImage-Datei (Kernel)
2. Bearbeitet die Datei piggy
3. Dazu öffnet ihr die Datei in einem Hex-Editor und geht zu dem vom Check-Script genannten Offset
4. Ändert die 01 in 00 und speichert die Datei
5. Packt den Kernel wieder zusammen. Dabei müsst ihr darauf achten, dass die Piggy benutzt wird, die ihr editiert habt, da es durchaus sein kann, dass das Script die Piggy aus Einzelteilen neu zusammensetzt.
6. Checkt den neuen Kernel mit tungstwentys Script. Als Output solltet ihr nun erhalten

7. Flasht diesen Kernel nun auf euer Handy.

Disclaimer:
Es kann keine 100% erfolgreiche Erkennung versprochen werden.
Der gepatchte Kernel sollte flashbar sein, jedoch wurde es nicht mit kompletten Unpack/Repack ausprobiert.


Originaler XDA-Thread:
[BrickBug][Fix][Kernel][01.08]Detection of stock kernel safety + patch guide - xda-developers
Script und Thread erstellt durch Tungstwenty (unteranderem für den CRT-Flicker-Bug-Fix sowie 4.0.4 Kamera-Bug-Fix verantwortlich)


@Mods: Sollte dieser Thread im falschen Bereich gelandet sein, verschiebt ihn bitte. Da der Kernel-Bereich nur für die Vorstellung von Custom-Kernel ist, habe ich mich erstmal dazu entschieden, ihn im Root/Hacking/Modding/Bereich zu posten.

Erst mal danke für diese einfache methode der überprüfung. Allerdings scheint sie nur bei Stockkerneln zu funktionieren?!
Wollte auch mal den Speedmod k3-30 damit testen. Leider kommt es hierbei zu einer Fehlermeldung, weiß jemand wieso?

Guck mal auf den Thread-Titel
Und im Originalthread bei XDA:
"However, for custom kernels I won't expect the code patterns to be always the same and therefore it's possible that the detection cannot be performed - you will see that in the output."
Übersetzt: Das Code-Muster kann in Custom-Kerneln anders sein, weswegen eine Erkennung nich möglich sein könnte. Dies wird durch die Ausgabe wiedergegeben.

Sorry für meine dämliche Frage...
Wer lesen kann ist klar im Vorteil

Allgemeine Anleitung zum Beheben des Bugs gepostet. Ich hab mit tungstwentys Hilfe und so für mich einen gefixten XWLPT Kernel, konnte ihn jedoch noch nicht auf Bootfähigkeit testen. Sobald ich das bewerkstelligt habe kann ich es hier posten mit dazugehörigen Links.

Gibt jetzt schonmal ein Danke für den fertigen XWLPT-Kernel, damit ich das SGS2 von meiner besseren Hälfte mal wieder auf den neuesten Stand bringen kann ;-)

@ topas: Ich wusste, ich hab was vergessen

__________________

@kangaroo
Nimm für den Zweck mal lieber den Siyah. Ich kann für nichts garantieren. Und bis ich die XWLPT drauf habe kann das noch dauern, das Wochenende bin ich stark mit Geburtstagen beschäftigt.

äääh - wadde ... bin mir jetzt nicht sicher ... aber wenn ich Siyah flashe, und was flashe ich dann als Stock?

Was hat denn Siyah jetzt mit Stock zu tun?

__________________
SGS II mit XWLSD
SGS IV

Checkliste