Tab kaputt geflasht?

[pibach]

Ganz im Gegenteil. Meine Schlussfolgerung von damals wird dadurch voll umfänglich und uneingeschränkt bestätigt.

Wo ließt Du das? Ich lese da was völlig anderes als Du sagst, u.a. eindeutig in der Zusammenfassung.
Mag ja sein, dass Du Recht hast.
Aber Widerspruch ist nun mal "eindeutoig" da. Was Du als "eindeutig" bezeichnest ist also schon mal nicht so.
In sofern weiß ich da gar nicht, was ich nun annehmen kann.
Könntest Du das denn begründen? Ausserhalb von "Beobachtungen"?
Bisher hört sich das für mich nach Kokolores an.
Passt aber ins Bild mit den andere Sachen, die Du erzählt hast (sorry, ist aber so).

 

[frank_m]

Also wenn ich in die Zusammenfassung des Brick Bugs schaue, dann finde ich da folgende Aussagen:

Der Stock Kernel (4.0.4, ohne root und CWMR) kann bugfrei per "Werkseinstellungen" oder "TelefonCODE" zurückgesetzt werden.

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) 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.

Das passt exakt zu dem, was ich oben beschrieben habe: Samsung Stock ist sicher, Custom Recoveries mit make_ext4fs() sind der gefährliche Teil.

 

[pibach]

Also wenn ich in die Zusammenfassung des Brick Bugs schaue, dann finde ich da folgende Aussagen:


Das passt exakt zu dem, was ich oben beschrieben habe: Samsung Stock ist sicher, Custom Recoveries mit make_ext4fs() sind der gefährliche Teil.

Ne, passt nicht wirklich.
Die normale Recovery benutzt den Aufruf lt. dem Posting auch. Also ist das aus dem Einstellungsmenü offenbar anders gelöst. Ob das stimmt?
Jedenfalls ist die Ursache nicht wirklich was mit dem Recovery (oder CWM, beide sind ja diesbezüglich wohl gleich), sondern der Kernel. So steht das da. Ob es stimmt? Müsste demnach aber auch mit patched Kernel und einem Recovery sicher sein. Zumindest werden da einige Kernel als sicher angegeben. Ob das dann auch stimmt ist aber wohl nicht so klar. Fazit ist ja dort "Grosse Ungewissheit".

Der ursprüngliche Beitrag von 00:20 Uhr wurde um 00:39 Uhr ergänzt:

Es ist denkbar, dass das geht. Normalerweise muss aber im laufenden Android der USB Debug Modus aktiviert werden, damit adb im Recovery aktiv wird. Die Einstellung ist bei dir momentan nicht aktiv, da deine Datapartition ja im Idealfall leer ist (sofern sie nicht defekt ist).

Hm. Noch mal langsam.
Wenn man bei laufendem Android USB Debugging aktiviert, ist es nicht nur dann aktiv, sondern auch nach Reboot ins Recovery?? Dann wäre das da ja immerhin implementiert. Und vielleicht per default immer an. Oder?
Aber was hat das mit leerer Datenpartition zu tun??

Ich hab keine Ahnung, ob jemand ein Recovery gebaut hat, dass ADB ohne USB Debugging aktiviert. Probiere es aus..

Wie sonst haben die anderen wohl auf ihren "gebrickten" Tabs diese ganzen Tools ausgeführt?

 

[frank_m]

Die normale Recovery benutzt den Aufruf lt. dem Posting auch.

Wo steht das?

Jedenfalls ist die Ursache nicht wirklich was mit dem Recovery (oder CWM, beide sind ja diesbezüglich wohl gleich), sondern der Kernel.

Wo steht das?

Müsste demnach aber auch mit patched Kernel und einem Recovery sicher sein.

Ich zitiere einfach mal den XDA Thread.

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

Also klare Aussage: Ein sicheres Recovery mit einem Stock Kernel ist die einzig sichere Variante. Alles andere ist potentiell unsicher.

Zumindest werden da einige Kernel als sicher angegeben.

Es ist denkbar, dass die Kernel sicher sind. Wie ich oben schon schrieb: Ich weiß es nicht. Im Zweifel wäre ich aber eher vorsichtig. Bislang hat niemand bewiesen, dass die Kernel wirklich sicher sind. Die Aussage, dass diese Kernel sicher sind, stammt aus einer Zeit, als man die make_ext4fs() Funktion noch nicht als Ursache ausgemacht hatte. Seit diese Erkenntnis vorliegt, müssen all diese Aussagen überdacht werden. Und wie ich auch schon festgestellt habe: Die Quote an Bricks mit den angeblich sicheren Kerneln ist erheblich. Deutlich größer, als mit Samsung Stock Kerneln. Das ist zwar kein Beweis, aber alle mal ein Grund zur Vorsicht.

Ob das dann auch stimmt ist aber wohl nicht so klar. Fazit ist ja dort "Grosse Ungewissheit".

Die große Unsicherheit bezog sich auf den anderen Thread, in dem überwiegend fast 6 Monate alte Erkenntnisse diskutiert wurden. Damals war die Unsicherheit groß, das ist unzweifelhaft. Wie Topas0815 ja auch im weiteren Verlauf des Threads schreibt:

Damit sind die Infos im aktuelleren Thema (dieser Zusammenfassung) natürlich "frischer" als die von vor nem halben Jahr und somit den älteren vorzuziehen. Wobei ich nicht sage das es, für den damaligen Stand der Erkenntnisse, falsch war. Heute wissen wir nur halt genaueres.

 

[pibach]

Also klare Aussage: Ein sicheres Recovery mit einem Stock Kernel ist die einzig sichere Variante. Alles andere ist potentiell unsicher.

Ja genau, so wird endlich ein Schuh draus!
Wobei der Stock Kernel dabei egal wäre, wenn der kritische Aufruf gar nicht erfolgt.
Darin sehe ich aber keine "neue Erkenntnis", sondern steht doch da überall so und ist auch nur logisch.
Ob dann ein gepatchter Kernel und ein "unsicheres" Recovery auch save wäre ist aber wohl weiterhin unklar.

Der ursprüngliche Beitrag von 01:35 Uhr wurde um 01:45 Uhr ergänzt:

Wo steht das?

das steht fett in Punkt 1 und 2 die Du oben zitiert hast.

make_ext4fs() Funktion noch nicht als Ursache ausgemacht hatte.

Es ist doch logisch, dass es irgendeinen Aufruf gibt. Das ist keine neue Erkenntnis. Und der Kernel setzt den dann um, und der ist falsch parametrisiert. Soviel wissen wir doch schon lange. Wenn man nun den Aufruf komplett umgeht, kann man auch den Kernelfehler umgehen. Soweit auch logisch. Ob die gepatchten Kernel sicher sind, bleibt unklar, solange man nicht genau weiß, wie dieses Kernel-Flag und die fehlerhafte eMMC Firmware zusammenspielen. Könnte man sich aber sicher anlesen.

Der ursprüngliche Beitrag von 01:45 Uhr wurde um 02:04 Uhr ergänzt:

Wear Leveling hat erst mal nichts mit defekten Blöcken zu tun, sondern verteilt Schreibzugriff nur zufällig auf die Blöcke im Flash. Und defekte Blöcke können nur so lange ausgetauscht werden, wie es Ersatzblöcke gibt. Sind alle verbraucht, ist der Flash kaputt. Ich hab in den verschiedenen Samsung Foren, in denen ich längerfristig aktiv bin (S1, S2, S3, Note, diverse Tabs) sicherlich schon 10 - 15 Fälle davon gehabt, (schon vor der Brick Bug Problematik).

Also Du meinst, dass die die Lebensdauer des Flash überschritten? ALLE Zellen 10.000-100.000 mal beschrieben? Wie alt und "durchgeflasht" waren die dann wohl? Und was sind die genauen die Specs des eMMC Chips im Tab 7.7? Mag ja ne Restwahrscheinlichkeit dafür geben, dass das so stimmt. Viel wahrscheinlicher ist doch aber, das diese Aussage schlicht falsch ist: "...die nachweisbar darauf zurückgingen"

 

[frank_m]

das steht fett in Punkt 1 und 2 die Du oben zitiert hast.

Nein, das steht nicht da. Du scheinst davon auszugehen, dass sich diese Aussagen auch auf das Samsung Recovery beziehen. Das ist natürlich nicht so. Über das Samsung Recovery kann man diesbezüglich keine Aussagen machen, da man überhaupt nicht weiß, wie es arbeitet. Davon gibt es keinen SourceCode. Diese Aussagen beziehen sich allesamt auf Recoveries, die gegen den CWM Sourcecode gebaut worden sind.

Es ist doch logisch, dass es irgendeinen Aufruf gibt. Das ist keine neue Erkenntnis. Und der Kernel setzt den dann um, und der ist falsch parametrisiert.

Den Beweis hat bislang niemand erbracht. Wie gesagt: Der Stock Kernel, der mit einem Custom Recovery zur Katastrophe führt, ist mit dem Samsung Recovery sicher. Das schreibt ja auch Entropy512 in seinen xda Beiträgen und in seinem Google+ Blog: Die Samsung Stock Recovery ist sicher. Alle Leute, die ihre Geräte gebrickt haben, haben definitiv ein Custom Recovery benutzt - entweder ein permanent geflashtes, oder eines dieser temporären Recoveries, die in vielen Root-Paketen angeboten werden.

Wenn man nun den Aufruf komplett umgeht, kann man auch den Kernelfehler umgehen.

Das kann sein. Es kann auch nicht sein. Wie gesagt: Der Beweis dafür steht aus. Und die Quote mit Bricks bei diesen angeblich sicheren Kerneln, die das fragliche Kommando umgehen, ist erheblich. Das ist ein Fakt, den niemand wegdiskutieren kann. Wenn du mir nicht glaubst, sieh dir den Thread im Note Forum an, der mich vor 3 Monaten zu der schon viel zitierten Aussage getrieben hat: Mehrere Fälle innerhalb weniger Tage. Alle beim installieren von CM, alle auf einem sicheren Kernel; und alle schwören, die Anleitung perfekt befolgt zu haben. Und alle Geräte haben den Brick.

Rekapitulieren wir noch mal, woher die Aussage mit dem Kernelfehler ursprünglich kommt. Plötzlich gab es diese große Anzahl an Bricks, die den Custom ROM Entwicklern bei xda auffiel. Niemand hatte am Anfang eine Erklärung dafür. Man fragte sich: Was hat Samsung da geändert? Der Kernel steht da natürlich ganz oben auf der List. Man hat den Source Code verglichen, und Bumm: Tatsächlich, da ist was. In den ICS Kerneln ist plötzlich das MMC_CAP_ERASE aktiviert. Eine Änderung im Flash Zugriff, und Flash geht plötzlich kaputt. Das muss es dann ja wohl sein. Die Schlussfolgerung war so überzeugend, dass sich Monate lang alle Leute nur darauf konzentriert haben, dieses MMC_CAP_ERASE zu umgehen. Und wenn es einen Brick gab, der "eigentlich" nicht sein durfte, dann gab es Ausflüchte: Die Anleitung wurde nicht befolgt oder einfach Pech gehabt. Es ist einfacher, den Fehler bei anderen zu suchen, als bei sich selber. Vor allem, wenn man sich so sicher ist, die eigentliche Fehlerursache längst identifiziert zu haben.
Erst als man dann eine größere Anzahl von Bricks hatte und vergleichen konnte, bei welchen Gelegenheiten die auftraten, kamen einigen langsam Zweifel an dieser Theorie: Warum betrifft es ausschließlich Custom ROMs? Warum auch bei sicheren Kerneln? Warum nie Leute mit Samsung Stock Software? Warum fixt Samsung den Bug nicht, obwohl sie erwiesenermaßen davon wissen? Andere kritische Firmwarebugs haben sie innerhalb weniger Tage gefixt, und sowas in Monaten gar nicht?
Such den Fehler. Die Antwort war irgendwann offensichtlich, es musste nur noch die passende technische Begründung dafür gefunden werden. Die haben wir nun.

Ob die gepatchten Kernel sicher sind, bleibt unklar, solange man nicht genau weiß, wie dieses Kernel-Flag und die fehlerhafte eMMC Firmware zusammenspielen.

Die Firmware des Flashcontrollers ist mittlerweile auch raus. Es gab ja mal diese Tools, die die Firmware des Chips prüften und daraus die Aussage generieren "Du bist betroffen" und "du bist sicher". Aber wie das so ist mit 6 Monate alten Aussagen: Es gibt mittlerweile auch genug Bricks mit den Controller Firmwares, die mal als sicher galten.

Also Du meinst, dass die die Lebensdauer des Flash überschritten? ALLE Zellen 10.000-100.000 mal beschrieben?

Nein, nicht alle. Eine reicht. Wie gesagt: Flash ist empfindlich, und es gibt schon bei Auslieferung auf dem Wafer keinen Flash Chip, der nicht schon ein paar defekte Sektoren hat. Die Anzahl der Schreibzugriffe ist ein Durchschnittswert bezogen auf den gesamten Flash und basierend darauf, dass es genug Ersatzzellen gibt, auf die ausgewichen werden kann.

Wie würdest du es denn erklären, wenn zu Zeiten, als es den Superbrick noch nicht gab, nachweislich Flashspeicher Bereiche kaputt waren, die sich weder lesen noch beschreiben ließen?

 

[pibach]

Nein, das steht nicht da. Du scheinst davon auszugehen, dass sich diese Aussagen auch auf das Samsung Recovery beziehen.

Ich lese nur was da steht und Recovery bezieht sich so wie es da steht auf das Stock Recovery, ansonsten würde da wohl CWM stehen. In der Zusamenfassung steht auch:

Wie äussert sich der bug

Wenn ihr, mit dem Stock Kernel, im Recovery einen full wipe macht (data/factory reset)

Das bezieht sich ja wohl auch auf Stock Recovery.
Macht auch Sinn, wenn es an der Funktion liegt, die sich bei ICS geändert hat, wäre ja komisch, wenn die ICS Stock Recovery gegen eine Gingerbread Version kompiliert worden wäre.

Das ist natürlich nicht so.

"natürlich"? Das schreibst Du oft, komischer Weise gerade bei Aussagen, die eben fraglich sind. Irgendwann ist das nicht mehr erst zu nehmen.
Wenn wir in der Diskussion irgenwas rausfinden wollen, wäre es hilfreicher, wenn Du klarere Statements machst, und Dinge, die Du nicht wirklich aussagen kannst auch nicht behauptest, oder aber begründest. Ansonsten bleibt durchgänging zu viel Unsicherheit in deinen Aussagen. Das hat nun schon zu erheblichem sinnlosen Geschreibsel geführt, hätte man alles viel kürzer haben können.

Über das Samsung Recovery kann man diesbezüglich keine Aussagen machen, da man überhaupt nicht weiß, wie es arbeitet. Davon gibt es keinen SourceCode. Diese Aussagen beziehen sich allesamt auf Recoveries, die gegen den CWM Sourcecode gebaut worden sind.

Ist der Samsung Code nicht zugänglich? Müsste doch alles Open Source sein. Oder?
Wäre denkbar, dass Samsung da einen speziellen Code in der Recovery nutzt, ja. Aber man weiß ja: es liegt an der Library-Funktion, die ja zu ICS gehört. Der Workaround nutzt die alte Funktion aus Gingerbread, die den fraglichen Kernelaufruf wohl blockt (schon komisch, aber genauer hab ich das bisher nicht verstanden).
Wobei auch im Gingerbread Kernel das MMC_CAP_ERASE gesetzt ist (?). Offenbar wird dann aber kein "stMMC erase, and just a format" ausgeführt, wie ja Entropy512 vorschlägt, um sicher zu sein.

Den Beweis hat bislang niemand erbracht. Wie gesagt: Der Stock Kernel, der mit einem Custom Recovery zur Katastrophe führt, ist mit dem Samsung Recovery sicher. Das schreibt ja auch Entropy512 in seinen xda Beiträgen und in seinem Google+ Blog: Die Samsung Stock Recovery ist sicher.

Verlink das doch mal bitte, hab ich nicht finden können.

Alle Leute, die ihre Geräte gebrickt haben, haben definitiv ein Custom Recovery benutzt - entweder ein permanent geflashtes, oder eines dieser temporären Recoveries, die in vielen Root-Paketen angeboten werden.

ok, das hab ich nicht so verfolgt wie Du. Ist aber in der Diskussion hilfreicher, wenn Du diese Info gibst, statt der Schlussfolgerung, die man ja erstmal für falsch halten muss nach dem bisher zu Lesenden darüber.

Wenn du mir nicht glaubst, sieh dir den Thread im Note Forum an, der mich vor 3 Monaten zu der schon viel zitierten Aussage getrieben hat: Mehrere Fälle innerhalb weniger Tage. Alle beim installieren von CM, alle auf einem sicheren Kernel; und alle schwören, die Anleitung perfekt befolgt zu haben. Und alle Geräte haben den Brick.

Link?
Kann aber auch andere Gründe haben, z.B. update.zip oder sowas.
Du solltest daraus jedenfalls keine zu voreiligen Schlüsse ziehen, das muss man erstmal genauer prüfen. Ohne erase kann es eigentlich nicht zu dem Problem kommen, wenn das also abgeschaltet wird, ist das auch sicher.

Rekapitulieren wir noch mal...Die Antwort war irgendwann offensichtlich, es musste nur noch die passende technische Begründung dafür gefunden werden. Die haben wir nun.

??
Wo gibt es dazu eine Begründung?

Die Firmware des Flashcontrollers ist mittlerweile auch raus. Es gab ja mal diese Tools, die die Firmware des Chips prüften und daraus die Aussage generieren "Du bist betroffen" und "du bist sicher". Aber wie das so ist mit 6 Monate alten Aussagen: Es gibt mittlerweile auch genug Bricks mit den Controller Firmwares, die mal als sicher galten.

Tatsächlich?
Link?
Wäre ja komisch.
Läge dann aber trotzdem wohl an (immer noch vorhandenem) Fehler in der Firmware des Flashspeichers.

Nein, nicht alle. Eine reicht. Wie gesagt: Flash ist empfindlich, und es gibt schon bei Auslieferung auf dem Wafer keinen Flash Chip, der nicht schon ein paar defekte Sektoren hat. Die Anzahl der Schreibzugriffe ist ein Durchschnittswert bezogen auf den gesamten Flash und basierend darauf, dass es genug Ersatzzellen gibt, auf die ausgewichen werden kann.

Wie würdest du es denn erklären, wenn zu Zeiten, als es den Superbrick noch nicht gab, nachweislich Flashspeicher Bereiche kaputt waren, die sich weder lesen noch beschreiben ließen?

Dass der Flashspeicher "durchgeflasht" ist, ist jedenfalls erstmal auszuschließen, schlicht zu unwahrscheinlich (schon merkwürdig, dass wir das diskutieren müssen). Würde wenn überhaut dann auch nur auf stark genutzte Geräte zutreffen können. Der Grund wird ein korruptes Filesystem oder ähnliches sein, müsste man sich genauer anschauen.

 

[frank_m]

In der Zusamenfassung steht auch:

Wie äussert sich der bug

Wenn ihr, mit dem Stock Kernel, im Recovery einen full wipe macht (data/factory reset)

Das bezieht sich ja wohl auch auf Stock Recovery.

Du hast mal wieder nicht bis zu Ende gelesen (das hatten wir schon). Erklär mir mal, wie man im Stock Recovery ein Nandroid Resotore machen kann.

Das schreibst Du oft, komischer Weise gerade bei Aussagen, die eben fraglich sind.

Die Aussagen sind nicht fraglich. Lies dir den verlinkten xda Thread durch, das steht alles da. Du schreibst ja selber, dass du den Überblick nicht so hast und es so detailliert verfolgst, wie ich. Ich hab dir hinreichend Quellen für meine Aussagen genannt. Wenn du sie anzweifeln willst, dann belege das Gegenteil.

Ist der Samsung Code nicht zugänglich? Müsste doch alles Open Source sein. Oder?

Nein, das ist kein Open Source. Open Source ist ja nur das, was im Rahmen des Android Open Source Projektes (AOSP) veröffentlicht wird. Ergänzungen und Erweiterungen dazu müssen die Hersteller auch wieder offen legen. Aber es hält sie niemand davon ab, es durch eigenen Code zu ersetzen.

Es gibt ein Recovery im AOSP, aber das stellt nur sehr rudimentäre Funktionen zur Verfügung. Deshalb macht eigentlich jeder sein eigenes. Samsung macht das, da sie selber etliche Funktionen hinzufügen, z.B. für ihre OTA Updates oder auch Unterstützung für spezifische Filesysteme auf verschiedenen Geräten. CWM ist das Recovery, die man in den Custom ROMs benutzt.
Die Code Basis für diese Recoveries ist also nicht identisch.

Samsung hat natürlich den Vorteil, die Dokumentation für die Firmware des Flashcontrollers zu haben. Die wissen also genau, wie das Ding zu bedienen ist. Dieses Wissen hat die Custom ROM Community nicht. Folglich ist da ein Fehler passiert, den Samsung natürlich vermieden hat. Das ist kein Vorwurf an die Community. Da die Dokumentation fehlt, muss man sich das alles mühselig per Reverse Engineering oder per "Trial and Error" erarbeiten. Dabei können solche Dinge passieren. Nicht umsonst steht in jeder Flashanleitung "Achtung! Du kannst dein Gerät zerstören".

Es ist nicht das erste Mal, das sowas passiert. Ähnliche Dinge passieren quasi immer, wenn man versucht, ein Custom ROM auf ein embedded Linux System zu bringen. Ich hab das bei d-Boxen, Fritzboxen und jetzt bei Android Geräten mitgemacht, und es gab früher oder später immer Dinge, die zur Zerstörung des Gerätes führen konnten. Besonders oft, wenn im Zuge einer neuen Gerätevorstellung seitens des Herstellers Dinge geändert wurden, und man seitens der Community erst mal versucht hat, wie vorher weiterzumachen. Genau das gleiche ist hier ja auch passiert.

Aber man weiß ja: es liegt an der Library-Funktion, die ja zu ICS gehört. Der Workaround nutzt die alte Funktion aus Gingerbread, die den fraglichen Kernelaufruf wohl blockt (schon komisch, aber genauer hab ich das bisher nicht verstanden).

Du hast es leider gar nicht verstanden. Die Kernelaufrufe können gar nicht geblockt werden von einer Library aus. Man ist gezwungen, die Kernelaufrufe zu verwenden, wenn man Zugriff aufs Flash will. Aber man muss es richtig tun, und das tun die Custom Recoveries eben nicht.

Wenn du das "del" Kommando in Windows benutzt, aber anschließend ist die ganze Festplatte leer, und nicht nur das Unterverzeichnis, welches du eigentlich löschen wolltest, wer ist dann schuld: Das "del" Kommando oder dein Aufruf?

Verlink das doch mal bitte, hab ich nicht finden können.

Hier. Entropy512 hat mal irgendwann eine Zusammenfassung der ganzen Ereignisse geschrieben, Mitte November war das glaube ich. Er hat sich auch mal mit Samsung Entwicklern getroffen, wo sie versucht haben, das Problem nachzustellen. Die Samsung Leuten hatten extra ein Galaxy S2 und ein Galaxy Note mit, bei denen die Flash-Bausteine gesockelt waren, um sie leicht austauschen zu können. Leider ist es in dem Meeting nicht gelungen, einen Brick Bug zu erzeugen, auch nicht mit gefährlichen Custom Recoveries. Einer der Samsung Entwickler hat dann erläutert, dass der Brick Bug wohl nur auf Flash Speicher auftreten kann, der schon ein paar Wochen in Benutzung ist (das war bei den mitgebrachten Flashbausteinen nicht der Fall). Warum das so ist, verrät Entropy512 aber auch nicht, da ihn der Samsung Entwickler um Verschwiegenheit gebeten hat.

Übrigens kommt Entropy zu dem Schluss, das Samsung das Problem auf Kernel Ebene möglicherweise leicht ausschließen könnte. Sie wollen das aber nicht, denn das würde die Schreib-Performance ins Flash um 10-20% verschlechtern. Ihre eigene Software kommt ja damit zurecht, und dass Custom Recoveries eine Gefahr darstellen, interessiert sie nicht. Eine ähnliche Einstellung seitens Samsung gibt es ja auch beim EFS: Solange ihre eigene Software läuft, interessiert es nicht, wenn es beim Modifizieren zu defekten Geräten kommen kann.

Link?
Kann aber auch andere Gründe haben, z.B. update.zip oder sowas.

https://www.android-hilfe.de/forum/...k-bug-thread.240563-page-32.html#post-3901471
Übrigens: Update.zips werden über CWM Recoveries und geflasht und machen Gebrauch der Funktionen des Recoveries - z.B. beim Zugriff aufs Flash. Eine CM Installation passiert über ein Update.zip, und im Laufe der CM Installation wird u.a. ein Wipe im CWM ausgeführt.
Update.zips sind also keine "anderen Gründe", sondern lösen nur automatisiert die gleiche Funktion im Recovery aus, vor denen eh gewarnt wird.

Du solltest daraus jedenfalls keine zu voreiligen Schlüsse ziehen, das muss man erstmal genauer prüfen. Ohne erase kann es eigentlich nicht zu dem Problem kommen, wenn das also abgeschaltet wird, ist das auch sicher.

Das mag sein. Es ist aber nicht abgeschaltet.

??
Wo gibt es dazu eine Begründung?

Hier auf deutsch oder Hier auf englisch.

Läge dann aber trotzdem wohl an (immer noch vorhandenem) Fehler in der Firmware des Flashspeichers.

Nein. Denke an das Windows "del" Kommando: Man muss die angebotenen Funktionen richtig benutzen. Samsung tut das in seiner Software. Die Custom ROM Community leider nicht.

Dass der Flashspeicher "durchgeflasht" ist, ist jedenfalls erstmal auszuschließen, schlicht zu unwahrscheinlich

Nee, das ist leider nicht zu unwahrscheinlich. Zugegeben, es trifft nicht viele Geräte, aber es ist nicht auszuschließen. Und deine Symptome sprechen immer noch dafür.
Festplatten, Waschmaschinen oder Auto-Motoren sollten ja auch nicht einfach so schon während der Garantiezeit kaputt gehen. Einige tun es aber trotzdem. Ähnlich ist es beim Flash.

 

[pibach]

Du hast mal wieder nicht bis zu Ende gelesen (das hatten wir schon). Erklär mir mal, wie man im Stock Recovery ein Nandroid Resotore machen kann.

Also ich hatte ja schon gesagt, dass ich genau lese. So auch hier. Nandroid mag zum CWM gehören, wird hier ja aber auch nicht unterschieden. Wir müssen das hier bitte nicht weiter diskutieren, so wie es da steht ist es eindeutig (und Du erzeugst da nur Irritationen).

Wenn du sie anzweifeln willst, dann belege das Gegenteil.

Ich weiß das nicht und müsste mich dazu einlesen. Das ist doch auch klar. Solange kann ich nur Plausibilitätschecks machen, über die Aussagen soweit. Deine sind eben oft "Kokolores" das hat ja auch scheinbar System. Gab dazu ja nun schon einige Beispiel. Dazwischen steckt wohl einiges was auch zutrifft. Ist halt schwierig, das voneinander zu trennen. Anstrengend ist dabei diese besserwisserische Haltung.

Nein, das ist kein Open Source.

ok, verstanden, Danke.

den Samsung natürlich vermieden hat.

Wieder ein Satz mit "natürlich". Also ist das vermutlich falsch (so zumindest bisher meine Reaktion auf sowas). Dass die Community den Flashcontroller falsch bedient halte ich dagegen erstmal für viel unwahrscheinlicher. Genaues weiß man aber eben wohl nicht. Oder?

und es gab früher oder später immer Dinge, die zur Zerstörung des Gerätes führen konnten.

Hört sich dubios an.
Ist mir auch nichts dergleichen bekannt.

Du hast es leider gar nicht verstanden. Die Kernelaufrufe können gar nicht geblockt werden von einer Library aus.

Es wird vermutlich ein format statt des erase genutzt, so wie ich schrieb.

...und das tun die Custom Recoveries eben nicht.

was die Frage wäre.

Hier. Entropy512 hat mal irgendwann eine Zusammenfassung der ganzen Ereignisse geschrieben, ...

finde da nichts.

Ihre eigene Software kommt ja damit zurecht...

Zunächst müsste das erstmal geklärt werden. Ist es das? Natürlich?

und dass Custom Recoveries eine Gefahr darstellen, interessiert sie nicht.

Halte ich nicht für plausibel, dass sie das nicht interessiert.

Eine ähnliche Einstellung seitens Samsung gibt es ja auch beim EFS: Solange ihre eigene Software läuft, interessiert es nicht, wenn es beim Modifizieren zu defekten Geräten kommen kann.

ist doch aber keine Erfindung von Samsung, sondern auch bei anderen Herstellern so, oder? Ein so kollektiv unsauber programmierter Code ist halt erstmal als sehr unwahrscheinlich anzunehmen. Wenn doch wäre es ein grober Fehler - bitte nicht wieder wegdiskutieren.
Dieses Problem müsste dann auch klarer bennant sein in er Community (xda developers). Und untersucht. Ist es das denn?

sondern lösen nur automatisiert die gleiche Funktion im Recovery aus, vor denen eh gewarnt wird.

es ist die Library-Funktion die eine Kernelfunktion aufruft und zwar erase. Wird umgangen durch format. Bitte nicht immer alles durcheinander werfen!

Nee, das ist leider nicht zu unwahrscheinlich. Zugegeben, es trifft nicht viele Geräte, aber es ist nicht auszuschließen. Und deine Symptome sprechen immer noch dafür.
Festplatten, Waschmaschinen oder Auto-Motoren sollten ja auch nicht einfach so schon während der Garantiezeit kaputt gehen. Einige tun es aber trotzdem. Ähnlich ist es beim Flash.

Blödsinn, sorry. Was soll man da noch sagen?

 

[frank_m]

Ich beende die Diskussion an dieser Stelle. Du bist offensichtlich unbelehrbar. Lies einfach die Quellen, die ich dir angegeben habe, da findest du alle meine Aussagen bestätigt, und deine eigenen Schlussfolgerungen widerlegt.

Dein Tab ist kaputt, ob nun durch einen Defekt oder durch eine fehlerhafte Flashoperation, sei dahingestellt. Ob ein Reflashen mit modifizierten PITs zum Erfolg führt, werden wir wohl nicht mehr herausfinden, da wir nicht in der Lage sind, die erforderlichen Informationen vorab zu erlangen. Also bleibt nur einschicken.

 

[wohak]

OT ...Uff... OT Ende

 

[Domtel]

Hallo zusammen,
hier wurde zwar bisher nur das Problem von Pibach diskutiert, aber da die Übrschrift passt packe ich meines mal dazu. Ich wäre sehr dankbar für Hilfe.

Ich habe mein Galaxy tab 7 plus N 3G (GT-P6201) mit Odin auf JB geflasht, die Version für das P6200, also die "nicht deutsche" Variante. Nun erkennt das Tablet keine Simkarten mehr. In der Hoffnung das Problem zu beheben habe ich dann wieder die Original-Version geflasht, sprich ICS für das P6201, was nicht half.

Ein paar Daten noch:
Meine (Original-) IMEI ist noch da, IMEISV ist 02, Basebandversion ist P6201XXLP3. Mit dem App "CSC Select" habe ich nachgesehen welchen Code ich habe, es ist DBT, also wohl richtig. Jetzige Kernel_Version 3.0.15-1115233 und falls es was nutzt Buildnummer IMM76D.XXLPC

Ich habe mich beim Flashen an die Anleitung von Frank gehalten und mir die Beiträge im hieisgen Forum zum Update für das 7 Plus und die Erfahrungen der Leute mit dem Flashen durchgelesen. Einen wichtigen Punkt habe ich leider weggelassen: EFS Backup nicht gemacht. Asche auf mein Haupt, ich weiß das war (sehr) dumm und wenn es daran nun scheitert ist es halt so.

Ausser dem Problem mit der Simkartenerkennung funktioniert das Tablet allerdings fehlerlos, auch Wlan usw. Im Zweifel muss ich mich halt damit abfinden 3G geschrottet zu haben...

Mein 1. Frage nun: Ist es möglich irgentwie auszuschließen, das einfach nur der Slot kaputt ist? Ich habe einen Simkartenadapter verwendet (Mikro auf normal) und in Foren gelesen, das dies schon bei einigen Tabs der Galaxy Reihe zu Beschädigungen führte.

2. Frage: Angenommen, dass es nicht der Slot ist, wie kann ich zumindest das EFS Problem ausschließen/bestätigen. Wie gesagt richtige IMEI ist noch vorhanden.

Falls noch weiter Informationen nötig sind reiche ich sie gern nach...

Viele Grüße Domtel