Tab kaputt geflasht?

[frank_m]

Ich hatte dir schon eher gesagt: Lies einfach nur präzise, was da steht und ziehe nicht selber irgendwelche Schlüsse oder interpretiere irgendwelche Phantasie-Informationen in das Geschriebene. Das geht bei dir hoffnungslos schief, wirklich jedes Mal.

Die "mysteriösen Programmierfehler" sind ein Produkt deiner Phantasie. Dass der Samsung Kernel am Brick Bug Schuld sein soll. ADB für den Flash Zugriff. Recovery für IMEIs. Die Notwendigkeit von EFS Backups, ...

Und natürlich die data.img. Jetzt schau noch mal in Ruhe. Was steht bei "Flashen mit Odin"? Und wo steht die data.img?
Die data.img steht bei "Zusatzinfos fürs Flashen", und zwar im Kapitel "Aufbau einer Firmware". Und es steht groß und breit dabei "Nicht alle Bestandteile sind zwingend erforderlich". Nirgendwo steht, dass eine data.img geflasht werden muss.

 

[pibach]

SIM Lock ist nur eines der möglichen Symptome. Es gibt zahlreiche andere, wie z.B. Entwickler IMEI, KOR ProductCode, usw.

Also noch mal langsam:

KOR Ländercode deutet darauf hin, dass man entweder nicht zusammenpassende Codes geflasht hat, oder den CSC Teil nicht geflasht hat, denn dann gehts auf default, also KOR. Das hat noch nichts mit defektem EFS zu tun. Wie man nun vorgenen sollte, wenn man das bemerkt (das haben ja sehr viele) ist mir noch nicht klar, offenbar kann man aber mit Flashen eine vollständigen Firmware das Problem ohne Schäden beheben. Korrekt? Wenn man stattdessen unvollständiges Flasht (was auch immer das genau heißt) dann kommt es eben zu "merkwürdigen" Zugriffen auf die EFS. Ich würde das schon klar einen Programmierfehler nennen, denn eigentlich sollte unter keinen Umständen die EMEI verloren gehen, oder? Und das Flashen neuer (Custom) Firmware ist eigentlich ein ganz normaler Vorgang, ähnlich wie Linux statt Windows auf dem Laptop. Ob Samsung sich dagegen verwehren kann und damit Garantie hinfällig wird ist ja auch juristische Grauzone. Solche Klauseln dürften in Zukunft wohl entfallen. Ist aber ein anderes Thema.

Der ursprüngliche Beitrag von 22:28 Uhr wurde um 22:34 Uhr ergänzt:

Nirgendwo steht, dass eine data.img geflasht werden muss.

Das hat doch auch niemand behauptet. Ich bin im übrigen ein recht präzieser Leser (und Schreiber). Was heißt das nun, wenn man die data.img, die von Dir bgepostet wurde in das tar einbezieht und flasht? Und wieso sollte man das nicht tun? Oder doch? Unklar.
Ist aber auch egal, muss man ja nicht alles haarklein zerreden. Mir geht es lediglich darum, das Tab wiederzubeleben - und da wäre ich für einen Hinweis dankbar.

 

[frank_m]

KOR Ländercode deutet darauf hin, dass man entweder nicht zusammenpassende Codes geflasht hat, oder den CSC Teil nicht geflasht hat, denn dann gehts auf default, also KOR. Das hat noch nichts mit defektem EFS zu tun.

Doch, natürlich. Der ProductCode ist doch ebenfalls im EFS gespeichert. Siehe Flashanleitung.

Wie man nun vorgenen sollte, wenn man das bemerkt (das haben ja sehr viele) ist mir noch nicht klar, offenbar kann man aber mit Flashen eine vollständigen Firmware das Problem ohne Schäden beheben. Korrekt?

Nein. Siehe Flashanleitung.

Wenn man stattdessen unvollständiges Flasht (was auch immer das genau heißt) dann kommt es eben zu "merkwürdigen" Zugriffen auf die EFS.

Falsch. Siehe #344 dieses Threads.

Ich würde das schon klar einen Programmierfehler nennen, denn eigentlich sollte unter keinen Umständen die EMEI verloren gehen, oder?

Wenn du dein Gerät unsachgemäß behandelst? Wie soll Samsung da verhindern, dass Dinge passieren, die du nicht willst?
Wenn du nicht willst, dass deine IMEI flöten geht, dann flashe nicht mit Odin an deinem Tab herum. So einfach ist das.

Und das Flashen neuer (Custom) Firmware ist eigentlich ein ganz normaler Vorgang, ähnlich wie Linux statt Windows auf dem Laptop.

Nein. Das wird explizit in der Anleitung und in den Garantiebedingungen von Samsung als "unsachgemäßer Eingriff" klassifiziert. Das ist überhaupt nicht mit einer Installation eines Rechners zu vergleichen. Sie schreiben extra deutlich in ihre Dokumentation, dass das Gerät davon kaputt gehen kann.

Der ursprüngliche Beitrag von 22:41 Uhr wurde um 22:45 Uhr ergänzt:

Ich bin im übrigen ein recht präzieser Leser (und Schreiber).

Das hast du bislang sehr erfolgreich verheimlicht.

Was heißt das nun, wenn man die data.img, die von Dir bgepostet wurde in das tar einbezieht und flasht?

Der Flashvorgang bricht ab. Kannst du nachlesen, ist diversen Leuten passiert.

Mir geht es lediglich darum, das Tab wiederzubeleben - und da wäre ich für einen Hinweis dankbar.

Das wurde ja nun oft genug beschrieben. Bau dir aus den vorhandenen Firmwares eine zusammen mit so viel wie möglich Bestandteilen und flashe die ohne PIT und Repart. Also genau das, was alle anderen vor dir in der Situation gemacht haben.

 

[pibach]

Das wurde ja nun oft genug beschrieben. Bau dir aus den vorhandenen Firmwares eine zusammen mit so viel wie möglich Bestandteilen und flashe die ohne PIT und Repart. Also genau das, was alle anderen vor dir in der Situation gemacht haben.

Ok, das ist mal endlich brauchbare Hinweis!
Verstehe nur nicht, warum Du das nicht gleich sagen kannst und so umschweifend komisches Zeugs erzählst, wirklich.

Der ursprüngliche Beitrag von 22:51 Uhr wurde um 22:55 Uhr ergänzt:

Doch, natürlich. Der ProductCode ist doch ebenfalls im EFS gespeichert. Siehe Flashanleitung.
...
Nein. Siehe Flashanleitung.
...
Falsch. Siehe #344 dieses Threads.

??
Damit kann ich wiederum nichts anfangen und verwirrt nur.
Was denn nun? Neu Flashen oder erstmal was zu EFS/KOR-Problem machen?

Der ursprüngliche Beitrag von 22:55 Uhr wurde um 23:00 Uhr ergänzt:

Der Flashvorgang bricht ab. Kannst du nachlesen, ist diversen Leuten passiert.

Ok, also so wie auch bei mir.
Dann ist das aber in der Anleitung eben wie gesagt irreführend.
Und warum du das data.img gepostet hast und das damals gehen sollte und jetzt nicht mehr bleibt auch unklar. Ist aber auch egal, ist nur unschön, dass Du mir diese Unstimmigkeiten vorwirfst, das muss doch nicht sein.

Der ursprüngliche Beitrag von 23:00 Uhr wurde um 23:08 Uhr ergänzt:

Nein. Das wird explizit in der Anleitung und in den Garantiebedingungen von Samsung als "unsachgemäßer Eingriff" klassifiziert. Das ist überhaupt nicht mit einer Installation eines Rechners zu vergleichen. Sie schreiben extra deutlich in ihre Dokumentation, dass das Gerät davon kaputt gehen kann.

Hierzu hab ich doch gesagt, dass das jur. Grauzone ist, und fraglich, ob die AGBs da überhaupt greifen, egal als was Samsung diesen Flashvorgang klassifiziert. Das kann man eben unterschiedlich sehen, ob es das selbe oder was anderes ist, als Betriebssystemwechsel auf einem Rechner. Wenn z.B. der Superbrickbug durch Fehler von Samsung verursacht wurde, dann ist das imho auch ein Garantiefall. Wie das im Zweifel juristisch ausgehen würde? Könnte vermutlich knapp sein.

 

[frank_m]

Ok, das ist mal endlich brauchbare Hinweis!
Verstehe nur nicht, warum Du das nicht gleich sagen kannst und so umschweifend komisches Zeugs erzählst, wirklich.

Du hast doch selber die ganze Zeit die anderen Fälle referenziert. Ich hab dir nur gesagt, flashe nicht die data.img und dir erklärt, was Tomsky gemacht hat.

Ob der Hinweis für dich brauchbar ist, wage ich allerdings zu bezweifeln. Gegen ein defektes EFS hilft das alles nicht. Du musst hoffen, dass die IMEI noch da ist. Sonst ist das alles vergeblich.

Was denn nun? Neu Flashen oder erstmal was zu EFS/KOR-Problem machen?

Wie willst du denn im momentanen Zustand was gegen das KOR Problem tun? Hast du dir angesehen, was dafür erforderlich ist?

Dann ist das aber in der Anleitung eben wie gesagt irreführend.

Alle anderen kommen damit zurecht.

Und warum du das data.img gepostet hast und das damals gehen sollte und jetzt nicht mehr bleibt auch unklar.

Lies es dir noch mal genau durch: Das war damals ein Versuch, weil es die data.img von Samsung nicht gab. Die wurde nie erfolgreich geflasht. Und ich habe dir gestern schon erklärt, dass man die data.img nicht mehr flashen muss! Jetzt werfe mir nicht vor, dass du nicht das getan hast, was ich dir gesagt habe, sondern irgendwas, was wir vor 6 Monaten mal experimentell versucht haben, und was erwiesenermaßen nie funktioniert hat, wie es auch überall steht!

Der ursprüngliche Beitrag von 23:11 Uhr wurde um 23:17 Uhr ergänzt:

Hierzu hab ich doch gesagt, dass das jur. Grauzone ist, und fraglich, ob die AGBs da überhaupt greifen, egal als was Samsung diesen Flashvorgang klassifiziert.

Es ist seit Jahren gerichtlich bestätigt, dass der Hersteller die sachgemäße Verwendung eines Gerätes beschreibt, und niemand sonst. Wenn du das Gerät unsachgemäß behandelst, hast du auf jeden Fall das Problem, dass sich die Beweislast umkehrt, auch schon innerhalb der ersten 6 Monate. Wie willst du Samsung beweisen, dass ein spezifischer Fehler nicht von dir verursacht wurde, wenn du Dinge getan hast, von denen selbst die Custom-Entwickler sagen, dass sie zur Zerstörung des Gerätes führen können?

Wenn z.B. der Superbrickbug durch Fehler von Samsung verursacht wurde, dann ist das imho auch ein Garantiefall.

Es ist ja nicht Samsungs Fehler, dass ist mittlerweile eindeutig klargestellt:
https://www.android-hilfe.de/forum/...eine-zusammenfassung.332877.html#post-4513608

 

[pibach]

Du hast doch selber die ganze Zeit die anderen Fälle referenziert. Ich hab dir nur gesagt, flashe nicht die data.img und dir erklärt, was Tomsky gemacht hat.

also ich finde diese Überheblichkeit langsam echt nervig. Auch wenn ich froh bin dass mir jemand hilft. Aber Du hast a) nicht gesagt, dass ich die nicht flashen soll, davon steht da nichts und b) hast Du mir nicht erklärt was Tomsky gemacht hat. Es ist auch unnötig darüber zu lamentieren, ist aber nervig, wenn Du ständig so vorwurfsvoll bist. Ich versuche lediglich das Problem zu verstehen und zu beheben.

Ob der Hinweis für dich brauchbar ist, wage ich allerdings zu bezweifeln. Gegen ein defektes EFS hilft das alles nicht. Du musst hoffen, dass die IMEI noch da ist. Sonst ist das alles vergeblich.

Das hab ich doch längst verstanden. Ist doch auch logisch, das fallst die EFS defekt ist, dann ein tieferes Problem vorliegt. Aber eine andere Wahl als neu Flashen zu probieren und zu hoffen hab ich ja nicht. Und ob tatsächlich ein EFS Problem vorliegt, wer weiß? Deine Hinweise sind dagegen immer irritierend, weil sie irgenwelchen mystischen Sachen oder unklaren Gefahren heraufbeschwören, ohne klare Handlungsalternative.

Wie willst du denn im momentanen Zustand was gegen das KOR Problem tun? Hast du dir angesehen, was dafür erforderlich ist?

Hab mir dazu viel angesehen. Und einige lösen es wohl ohne Probleme andere mit mehr Aufwand (JTAG?). Deine Hinweise dazu fand ich bisher aber nur irritierend.

Alle anderen kommen damit zurecht.

Mag ja sein, aber da ist offensichtlich diese Stelle nicht ganz aktuell, da gibt es doch nichts zu deuteln.
Inzwischen ist Dir ja bekannt, dass flaschen der Data.img nicht durchläuft.

Lies es dir noch mal genau durch: Das war damals ein Versuch, weil es die data.img von Samsung nicht gab. Die wurde nie erfolgreich geflasht. Und ich habe dir gestern schon erklärt, dass man die data.img nicht mehr flashen muss! Jetzt werfe mir nicht vor, dass du nicht das getan hast, was ich dir gesagt habe, sondern irgendwas, was wir vor 6 Monaten mal experimentell versucht haben, und was erwiesenermaßen nie funktioniert hat, wie es auch überall steht!

"überall steht"? Keine Ahnung wo das stehen sollte. Ich hab jedenfalls konkret danach gefragt und Du hast Dazu nicht verständlich geantwortet. So viel ist erst mal Fakt. Das macht ja nichts und ich kann verstehen, dass man genervt ist, bei sich ständig wiederholenden Fragen. Aber diese Vorwürfe von Dir sind nervig. Lass doch einfach weg.

Es ist seit Jahren gerichtlich bestätigt, dass der Hersteller die sachgemäße Verwendung eines Gerätes beschreibt, und niemand sonst. Wenn du das Gerät unsachgemäß behandelst, hast du auf jeden Fall das Problem, dass sich die Beweislast umkehrt, auch schon innerhalb der ersten 6 Monate. Wie willst du Samsung beweisen, dass ein spezifischer Fehler nicht von dir verursacht wurde, wenn du Dinge getan hast, von denen selbst die Custom-Entwickler sagen, dass sie zur Zerstörung des Gerätes führen können?

Im konkreten Fall müsste man nachweisen, dass der Defekt nicht "eigenverschuldet" ist. Hier kann man dann streiten, ob flashen bereits kategorisch ausgeschlossen werden darf (insbesondere, wenn es nicht mehr korrekt supportet wird) und ob der User mit so einem Brickbug (den wohl Samsung zu verschulden hat?) zu rechnen hat.
Ist jedenfalls nicht so kategorisch, wie du schreibst. Ansonsten möchte ich das Thema eigentlich nicht weiter vertiefen, ist ja hier nicht so relevant.

Es ist ja nicht Samsungs Fehler, dass ist mittlerweile eindeutig klargestellt:

Ist es das?
Da steht: schuld sind "Stock Kernel und fehlerhafter eMMC-Chip". Beides von Samsung. Oder?

Edit: genaugenommen ist es nicht direkt im Kernel sondern eine Library-Funktion ("Stock Kernel der das EMMC_CAP_ERASE beinhaltet"), die vom Recovery aufgerufen wird. Ändert aber nichts daran, dass der Fehler doch wohl vom Hersteller verursacht ist.

 

[frank_m]

Aber Du hast a) nicht gesagt, dass ich die nicht flashen soll, davon steht da nichts

Siehe Beitrag 5:

Das mit der data.img haut nicht hin. Die kann man nicht flashen.

Beitrag 9:

Nein! Du kannst die data.img auf dem Tab nicht flashen. Vergiss es. Lies die Berichte von allen, die es versucht haben.

und b) hast Du mir nicht erklärt was Tomsky gemacht hat.

Beitrag 7:

Er hat genau das getan, was ich gerade beschrieben habe: Die Bestandteile verschiedener Firmwares gesammelt, um möglichst viele Partitionen beim Flashen beschreiben zu können.

Deine Hinweise sind dagegen immer irritieren, weil sie irgenwelchens mystischen Sachen oder unklaren Gefahren heraufbeschwören.

Mystische Gefahren? Wenn dein Tab nicht mehr bootet und ProductCode KOR anzeigt, dann ist das alles andere als mystisch.

Hab mir dazu viel angesehen. Und einige lösen es wohl ohne Probleme andere mit mehr Aufwand (JTAG).

JTAG hilft nicht gegen ein EFS Problem. Keine Ahnung, wo du das wieder aufgesammelt hast.

Jetzt wird es albern.
Da ist offensichtlich diese Stelle nicht ganz aktuell.
Inzwischen ist Dir ja bekannt, dass flaschen der Data.img nicht durchläuft.

Wieso nicht ganz aktuell? Das ist doch wieder grober Unfug. Jetzt behaupte nicht, ich hätte irgendwas geschrieben, was nirgendwo steht!

• Die Firmware besteht nach wie vor aus den aufgezählten Komponenten. Dazu gehört auch die Data.img! Sieh in die Partitionstabelle deines Tabs, wenn du mir nicht glaubst. Genau so, wie ich es in der Anleitung beschrieben habe. Das Kapitel "Aufbau einer Firmware" ist exakt korrekt, so wie es da steht.
• In der Flashanleitung steht nirgendwo, dass du die data.img flashen sollst. Das stand nie da, und steht auch heute nicht da. Es kann auch gar nicht dastehen, da die Originalfirmware von Samsung immer unterschiedlich zusammengesetzt ist.

Die data.img zum Flashen taucht nur in den ersten Threads auf, als damals einige Leute falsche Firmware in ihre Tabs geflasht haben. Du kannst aber gerne nachlesen, dass data.img nie erfolgreich geflasht wurde, sondern Odin immer abbricht, wenn man versucht, die zu flashen. Hingegen haben mehrere Leute ihr Tab ohne data.img gerettet, indem sie nach dem Flashen einen Werksreset durchgeführt haben.

"überall steht"? Keine Ahnung wo das stehen sollte. Ich hab jedenfalls konkret danach gefragt und Du hast Dazu nicht verständlich geantwortet.

Was ist an "Das mit der data.img haut nicht hin. Die kann man nicht flashen" unverständlich? Oder an "Nein! Du kannst die data.img auf dem Tab nicht flashen. Vergiss es. Lies die Berichte von allen, die es versucht haben."

Ist es das?
Da steht: schuld sind "Stock Kernel und fehlerhafter Flash Speicher. Beides von Samsung. Oder?

Wo bitte schön liest du das denn nun schon wieder? Ich glaube, eines deiner Probleme ist, dass du nicht bis zu Ende liest. Du hörst zu früh auf und nimmst daher Dinge als gegeben an, die im weiteren Verlauf einer Diskussion widerlegt oder korrigiert werden. So ist es beim Flashen der data.img, und so ist es auch hier:

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

und später:

Um genauer zu sein, hat das sogar recht wenig mit dem Kernel zu tun, um nicht zu sagen : gar nichts.
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.

Ich glaube kaum, dass man Samsung vorwerfen kann, wenn Fremdsoftware Dinge tut, die das Gerät zerstören. Wieder gilt (wie beim Flashen): Benutzt man ausschließlich die Software, die von Samsung vorgesehen wurde, dann ist man auf der sicheren Seite!

 

[TimoBeil]

Sorry, wenn ich mich nur ganz kurz einmische:

@Frank: ich bewundere deine Geduld. Schaffst du das durch autogenes Training?

@ pibach: vielen Dank für den kurzweiligen Abend. Es mag sarkastisch sein, aber ich hätte nie gedacht, dass mich eine derart beharrliche Ignoranz (ja, auch wenn es weh tut, es ist aber leider so) dermaßen fesseln kann, dass ich gespannt auf jeden neuen Beitrag warte. Ich bin nun schon fast wieder geneigt, das alles als getürkt zu sehen - oder ist das wirklich alles dein Ernst?

Hau mich, wenn dir danach ist und du ein Ventil benötigst- eines Tages wirst du jedoch begreifen, dass du sowas von auf dem Holzweg bist. Wenn nicht, dann tut es mir wirklich leid...

 

[pibach]

also ich hab noch mal LQ2 mit param.lfs und boot.bin aber ohne die data.img geflasht. Läuft durch mit ok. Selber Fehlerzustand wie anfangs beschrieben, also häng beim Samsung Schriftzug beim Booten. Das selbe auch nach wipe cache und factory reset (das wohl nicht durchläuft sondern irgendwann schlicht rebootet). Das selbe Ergebnis liefer CWM format /data. In CWM kann ich eMMC unmounten/mounten aber sd card und data ergibt "Error mounting ..."

Irgendwelche Hinweise auf CRC Probleme werden nicht angezeigt. Könnte das trotzdem sein? Lässt sich das irgendwie prüfen?

Was lässt sich jetzt noch machen?

Im CMW kann ich z.B. format /sd card oder format /emmc wählen. Das bringt aber wohl nichts, sondern vernichtet dann ggf. auch die EFS Partition, oder?

Lassen sich andere Tools per update zip nutzen?

Edit: ein Terminal Emulator?
Oder per ADB? Dann müsste man wohl einen "Deamon" auf dem Tab installieren. Wie geht das? Oder kann es das per "default", d.h. kommt man irgendwie in den "USB Debug Modus"?). HG42 berichtet ja, dass der "Thor Kernel" angeblich direkt per ADB kommunizieren kann. Auf xda wird was von einem Abyss-Kernel geredet. Leider nur für das N7000 müsste aber natürlich auf dem P6800 ähnlich gehen. Dann hätte man weitere Möglichkeiten, z.B. mit e2fck, parted usw.

Hier werden ja Scripte angeboten, die den Flashspeicher testen sollen, müsste ja eigentlich auch auf dem tab laufen. Oder?

Falls positiv getestet, dann Umpatitionieren. Hat das schon mal jemand erfolgreich gemacht?

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

Hab mich noch mal etwas in diesen Brick Bug eingelesen.
Offenbar ist EMMC_CAP_ERASE keine Library Funktion, sondern ein Kernel Flag. Im Zusammenspiel mit dem "fehlerhaften" flash Speicher sorgt das beim wipen für Bugs. D.h. auch unter der Stock Recovery. Das ganz Wipen hätte ich also wohl lassen sollen...

Hier könnte es dann helfen, auf Gingerbread zu flashen oder da zu wipen?
Hatte damit jemand Erfolg?

Hier die schöne Zusammenfassung von HG42:

Um es nochmal für alle zusammenzufassen, so wie ich es im Moment kenne/sehe, langsam zum Mitschreiben:

Stock ICS und alle die denselben Kernel verwenden sind gerade das Problem (auch Nachfolger bis Samsung seine Kernel gefixt hat).
Diese Kernel lösen in Zusammenhang mit bestimmten eMMC Chips bzw. dessen Firmware den Super-Brick aus.
Es wird vom Kernel das ERASE-Kommando erlaubt, das wegen eines Fehlers(?) in der Chip-Firmware die Register falsch setzt und dadurch Blocks irgendwie "beschädigt".
Einige Operationen, wie z.B. das Löschen größerer Bereiche (wipe) setzen dann dieses ERASE-Kommando ein und es kommt zum Super-Brick.

Erschwerend kommt hinzu, dass ein wipe auch in anderen Operationen versteckt sein kann, z.B. wird beim Zurückspielen eines Backups vorher der alte Inhalt gelöscht, beim Installieren eines ROMs via CWM kann vorher die Partition gelöscht werden, usw.

Die Firmware kann man meines Wissens nicht einfach austauschen. Der Brick bewirkt soweit ich weiß, dass nach dem Lesen oder Schreiben der kaputten Blocks das gesamte Flash nicht mehr reagiert, wodurch sich das Gerät in der Regel ganz aufhängt (wahrscheinlich weil das Betriebssystem endlos auf eine Reaktion wartet).
Bei mir läuft aber z.B. die emmc check app auf der Stelle weiter, d.h. die Adresse wird nicht mehr hochgezählt, die Eieruhr läuft aber noch und die Zeit zählt hoch. Ich schätze das liegt daran, dass die App im RAM läuft und Zugriffe irgendwie abgebrochen werden, wenn sie zu lange dauern (Interrupt, eigener Thread, den man abschießen kann oder so).

Man sieht allein an der Länge des Textes, dass es sich um eine relativ komplexe Sache handelt. Das verwirrt viele, weil eine Logik manchmal schwer zu erkennen ist.

 

[truhlik]

Was lässt sich jetzt noch machen?
http://www.handy-faq.de/forum/samsu...te_n7000_erfahrungsbericht-3.html#post2097337:

Samsung-Service Anrufen und hoffen, das die das Gerät noch als Garantie
anerkennen.
Datrepair zuschicken. Da wird die Platine ausgetauscht. Dauert ungefähr
zwei Wochen.
Ich wünsche dir viel Glück.

 

[pibach]

Samsung-Service Anrufen und hoffen, das die das Gerät noch als Garantie
anerkennen.
Datrepair zuschicken. Da wird die Platine ausgetauscht. Dauert ungefähr
zwei Wochen.
Ich wünsche dir viel Glück.

Mein Tab ist übrigens aus der Schweiz. Trotzdem geht als Ansprechpartner wohl Samsung Deutschland. Und Datrepair ist dann wohl ausführende Werkstatt für Samsung?

Einschicken wäre letzte Option.
Allerdings kann ich ja per Odin oder Recovery alles mögliche Flashen. Da sollte doch noch was möglich sein, oder?
Oder gibt es für das Tab nichts Vergleichbares wie für das Note (also Abyss-Kernel oder dergleichen für Debug Mode)?

Bei dem eMMC Brick Bug tritt lt. bisherigen Beschreibungen eigentlich auch anders Symptome auf als mount problem.

i) Ich hab also entweder eMMC Brick Bug nur auf der data Partition. Sollte dann aber trotzdem mounten können.
ii) eMMC Fehler aus anderem Grund in der Data Partition. dito
iii) irgendein "EFS-Problem" (dessen Ursache und der Zusammenhang zum mount Problem mir noch nicht so klar ist).
iv) irgendein Initialisierungsproblem der data Partition (keine Ahnung, was das für Ursachen haben könnte)

Fall iv) ist ja wohl erstmal am naheliegendsten. Oder?

Tomsky hat den mount Fehler ja wohl so gelöst:

@frank_m: Danke für die data.img (und die detaillierte Partitions-Info! Hoffentlich hat Dein Media-Center nicht drunter gelitten...). Habe sie ins PDA.tar eingebaut und neu geflasht (3-teilige LQ1 + Repart). Ergebnis: der cannot_mount_data-Error kommt nicht mehr. Gut!

Die Aussage von Frank, dass es mit data.img irgendwie nicht mehr geht verstehe ich vor dieser Vorgeschichte nicht.

Weitere Ideen, was sich machen lässt gibt es aber offenbar hier nicht, oder verstehe ich das falsch?

Würde schon gerne in etwas wissen wollen, was das Tab denn hat, bevor ich das einschicke. Immerhin ist ja unklar, ob die das auf Garantie beheben und ausserdem dauert es dann auch.

 

[Lipi]

Hallo,

direkt an Datrepair senden, hat bei mir eine Woche gedauert. Die öffnen das Tab (minimale spuren) und bauen wie geschrieben ein neues Mainboard ein. Samsung wird dir genau das sagen.

Bei mir hatten sie aber auf AUT ein ATO geflasht. Hatte Glück, ging mit dem CSC-Flasher auf ATO.

Kam bei mir mit einem 3.2 an, das wirklich starke Probleme hatte. Keine Pin Eingabe möglich, kein GPS signal. Hab dann selber per Odin geflasht, hat nix gebracht. Nochmal eingesendet jetzt geht alles.

Momentan hab ich aber ein Problem mit der Bluetooth apt-x wiedergabe, mein Tab hängt sich auf. Jetzt kann ich aber nicht sagen, ob es am Tab oder an der Anlage liegt. Hab die Anlage erst nach meinem Brickbug gekauft.

Mein Gerät ist auch ein Schweizer Gerät, lies mal hier nach : https://www.android-hilfe.de/forum/...ndroid-gt-p6800-bootet-nicht-mehr.314976.html

Flowjob hat auch ein Schweizer Gerät und hat es in die Schweiz geschickt.
Scheint also auch zu klappen, Datrepair geht nur deutlich schneller und der Versand kostet weniger.

Viel Glück mit deinem Tab,

Lipi

 

[frank_m]

Das selbe auch nach wipe cache und factory reset (das wohl nicht durchläuft sondern irgendwann schlicht rebootet).

Das hört sich für mich nach einem Defekt im Flash an.

Es klingt blöd, aber ich glaube: Du hast einen ganz gewöhnlichen Defekt. Kein Brick Bug, kein komplett kaputtes EFS oder sowas, sondern einfach ein kaputtes Flash. Sowas hatten wir schon, wie gesagt. Natürlich ist es schwierig, unter den ganzen Möglichkeiten die richtige herauszufinden, aber die Symptome deuten für mich darauf hin.

Was lässt sich jetzt noch machen?

Du könntest versuchen, mit der Recovery Methode das Flash so weit zu verkleinern, dass das Tab wieder bootet. Ich bin aber skeptisch, dass das zum gewünschten Erfolg führt.

Edit: ein Terminal Emulator?
Oder per ADB? Dann müsste man wohl einen "Deamon" auf dem Tab installieren.

Für beides müsste dein Tab aber erfolgreich booten. Vorher läuft weder ADB noch ein Terminal Emulator.

HG42 berichtet ja, dass der "Thor Kernel" angeblich direkt per ADB kommunizieren kann. Auf xda wird was von einem Abyss-Kernel geredet. Leider nur für das N7000 müsste aber natürlich auf dem P6800 ähnlich gehen.

Nein, da arbeitet das Tab auch komplett anders, als das Note. Beim Tab sind Kernel und Recovery getrennt, wie auch bei den neueren Smartphones (S3 und neuer). Beim Note waren Kernel und Recovery noch eine Einheit. Evtl. gibt es ein passendes Recovery fürs Tab, ich kenne aber keines. Man muss aber klar festhalten: Wenn es das gibt, dann ist es extrem gefährlich, denn das ist nach aktuellen Erkenntnissen die Quelle für den Brick Bug!

Hier werden ja Scripte angeboten, die den Flashspeicher testen sollen, müsste ja eigentlich auch auf dem tab laufen. Oder?

Aber auch nur, wenn das Tab bootet.

Offenbar ist EMMC_CAP_ERASE keine Library Funktion, sondern ein Kernel Flag. Im Zusammenspiel mit dem "fehlerhaften" flash Speicher sorgt das beim wipen für Bugs. D.h. auch unter der Stock Recovery. Das ganz Wipen hätte ich also wohl lassen sollen...

Die Information ist hoffnungslos veraltet. Die nehmen sie nicht mal mehr im ägyptischen Museum, so alt ist die schon.
Die EMMC_CAP_ERASE ist vollkommen ungefährlich für das Flash, sowohl auf dem Note als auch auf dem Tab. Samsung Stock Kernel und Stock Recovery können jederzeit gefahrlos zum Wipen und flashen benutzt werden. Das Problem tritt nur in Zusammenhang mit Custom Recoveries auf. Die aktuellen Erkenntnisse dazu habe ich ja oben verlinkt. Du hast sie offensichtlich nicht gelesen und statt dessen auf Ausführungen vertraut, die ein halbes Jahr alt und längst überholt sind (das hatten wir ja schon öfter). Die neuen Infos sind seit ca. 2 Wochen bekannt und werden inzwischen auch bei XDA von allen führenden Entwicklern so bestätigt.

Die alte Erkenntnis konnte auch so nicht aufrecht erhalten werden. Dass die alten Verdächtigungen - nämlich ein Zusammenhang mit dem Samsung Stock Kernel - nicht mehr haltbar waren, habe ich vor drei Monaten schon behauptet:
https://www.android-hilfe.de/forum/...k-bug-thread.240563-page-32.html#post-3901471
Damals hat man mir dafür bei XDA noch fast den Kopf abgerissen (inkl. des Vorwurfs, ich müsse wohl für Samsung arbeiten, um sowas verrücktes behaupten zu können), mittlerweile ist es bewiesen.

Aber ich habe mich daran gewöhnt, dass man nicht auf mich hört und so unnötig viel Zeit verschwendet. Es ist halt einfacher, den Fehler auf andere zu schieben, anstatt bei sich selber zu suchen.

 

[pibach]

Das hört sich für mich nach einem Defekt im Flash an.

Es klingt blöd, aber ich glaube: Du hast einen ganz gewöhnlichen Defekt. Kein Brick Bug, kein komplett kaputtes EFS oder sowas, sondern einfach ein kaputtes Flash. Sowas hatten wir schon, wie gesagt. Natürlich ist es schwierig, unter den ganzen Möglichkeiten die richtige herauszufinden, aber die Symptome deuten für mich darauf hin.

Welche Symptome denn nun? Wie sollte man "normalen Flash Bug" von einem "Brick Bug" unterscheiden können?

Außerdem sollte der Flashspeicher doch gar nicht kaputt gehen können. Bei einem abgebrochenen Flashvorgang z.B. könnte es vielleicht theoretisch sein, dass der Bootsektor und das Recovery und gleichzeitig der Download Mode zerstört werden (mit falschen Daten beschrieben, so das es abstürzt). Dann wäre es tatsächlich "gebrickt". Aber eigentlich ist das extrem unwahrscheinlich.

Wie es jedenfalls zu einem physikalischen Fehler im Flashspeicher kommen sollen könnte , leuchtet mir nicht ein (bis auf das "Brick Bug Problem"). Und viele Meldungen dazu sind vielleicht ganz andere Fehler.

Edit: "kaputtes Flash" damit meinst Du vielleicht falsch beschriebe Speicherbereiche von einem Flash Vorgang? Dann könnte man das aber wohl durch entsprechendes Flashen auch wieder beheben. Austausch des Mainboards wäre dann nicht nötig.
Mich würde dazu interessieren, wie Datrepair z.B. entscheidet, in welchen Fällen sie das Mainboard tatsächlich austauschen. Eigentlich doch nur bei physikalischen Fehler, z.B. des eMMC. Ein EFS/EMEI Problem müsste man dagegen eigentlich per JTAG repariert bekommen. Und andere "unbootbare" Flashfehler wohl auch, oder?

Du könntest versuchen, mit der Recovery Methode das Flash so weit zu verkleinern, dass das Tab wieder bootet. Ich bin aber skeptisch, dass das zum gewünschten Erfolg führt.

"Recovery Methode"?
Also man könnte ein neues PIT File flashen und dadurch per Odin umpartitionieren. Das wäre aber ein totaler Blindflug. Der Weg über Tools wie parted geht ja nicht, wenn man das Tab nicht in den Debug Mode bekommt.

. Beim Tab sind Kernel und Recovery getrennt, wie auch bei den neueren Smartphones (S3 und neuer).

Man könnte also mit einem entsprechenden Recovery oder einem Kernel booten und dann ggf. in den Debug Mode.
Dass das Tab derzeit nicht bootet liegt ja vermutlich nur an der /data Partition. Ein anderer Kernel könnte ja da trotzdem drauf booten, ohne diese Partition. Ins Recovery kann ich ja auch booten. Ist also zumindest denkbar, wäre die Frage, ob es dafür Kernel oder Recovery mit entsprechender Funktion gibt.

Die eMMC-scan-scripte hatte ich eigentlich so verstanden, dass sie über die "update from zip" Funktion direkt aus dem Recovery gestartet werden können. Ist das überhaupt denkbar? Das Recovery müsste dazu vermutlich die entsprechende Scripting Basis bereitstellen (hab nicht genau verstanden, wie das gehen sollte). Unterschiede zw. Note und Tab gibt es diesbezüglich ja wohl nicht, oder?

Wenn es das gibt, dann ist es extrem gefährlich, denn das ist nach aktuellen Erkenntnissen die Quelle für den Brick Bug!

...mittlerweile ist es bewiesen.

Hab mir den von Dir verlinkten Thread durchgelesen und konnte keinen Bezug zu Deiner Aussage dort finden. Und die "Zusammenfassung" im ersten Posting wäre nach Deiner Aussage ja dann falsch und es kommt irgendwo hinten (wieso verlinkst Du das dann ohne Hinweis darauf??).
Ich lese auch an anderen Stellen (xda-develeopers) überall, dass es eine Kombination aus Kernel und eMMC Chip ist.
Verlink doch mal bitte die Stelle, die Du meinst.

Aber ich habe mich daran gewöhnt, dass man nicht auf mich hört und so unnötig viel Zeit verschwendet. Es ist halt einfacher, den Fehler auf andere zu schieben, anstatt bei sich selber zu suchen.

Kann mir aus Deinen Aussagen halt oft nichts sinnvolles zusammenreimen.
Liegt möglicherweise daran, weil Du die entscheidenden Hinweise (die Du im Hinterkopf hast) gar nicht nennst?
Das scheint Methode bei Dir zu haben.

War bis jetzt bei der data.img so, der Verlinkung der Brick Bug Ursache, Deiner Antwort auf meine Fragen nach ADB etc. Auch das mit den "unvorhergesehenen EFS Schreibzugriffen" und der Zerstörung des Gerätes, was Du beschrieben hattest - hört sich dubios an. Woher hast Du das? Wenn das stimmen sollte, wäre es ein himmelschreiender Programmierfehler von Samsung (oder Google?) und schon sehr komisch, wenn die sowas machen sollten. Vielleicht ist es aber auch ein Schutz gegen missbräuchliches Ändern der EMEI? Also z.B. unlocking. Sollte trotzdem nicht das Gerät zerstören, sondern schlicht Ausführung stoppen o.ä.

Der ursprüngliche Beitrag von 12:11 Uhr wurde um 14:08 Uhr ergänzt:

Hab noch mal probiert Android 3.2 drauf zu machen, und zwar P6800XXLA3, also die Schweizer Original-Firmware von Samfirmwares.

Flashen ging, Bootet wieder bis zum Samsung Logo und bleibt stehen. Im Recovery kriege ich wieder den mount /data Fehler - aber da steht nun auch wieder CSC = KOR.
Erstaunlicherweise lieft diesmal das Factory reset durch, meldet dann schließlich "format /data complete"!
Reboot landet allerdings im Boot Loop, also nur bis "Samsung Galaxy Tab 7.7" Logo, dann Absturz, warten, dann wieder irgendwann reboot.

Im Recovery ist jetzt der mount /data Fehler weg - das zumindest scheint behoben.

Hab aber "can't access to system/csc/KOR/system"

Edit:
Dann noch mal LQ2 Firmware geflasht. Bleibt bei Boot loop. Sag im Recovery aber "successfully aplied CSC code KOR".
Ein Factory Reset kam wieder nicht durch (keine Meldung sondern Reboot) - jetzt hab ich wieder stuck at Bootlogo Samsung, also wie gehabt.

 

[truhlik]

Hallo,
diese Diskussion hier bringt dich sowieso nicht weiter. Ich habe dir am 7.12. geraten das Gerät zuschicken. In einer Woche könntest du dein Gerät schon repariert zurück haben. Jetzt hat sich das nur verschoben. Ich hatte das gleiche gehabt, deswegen guter Rat (bleibt dir sowieso nichts anderes übrig) Samsung Service anrufen und an Datrepair zuschicken.

Viel Glück
truhlik

 

[frank_m]

Welche Symptome denn nun? Wie sollte man "normalen Flash Bug" von einem "Brick Bug" unterscheiden können?

Nur anhand der Symptome. Der "Brick Bug" betrifft in allen mir bekannten Fällen mehr als die /data Partition. Eben weil nur die /data bei dir betroffen ist, vermute ich einen anderen Defekt.

Außerdem sollte der Flashspeicher doch gar nicht kaputt gehen können.

Doch, klar. Flashspeicher ist sogar recht empfindlich. Es gibt extra ein Bad Block Management im Flash Speicher und eine gewisse Anzahl Reserve Blöcke, die benutzt werden können. Aber wenn die Reserve aufgebraucht ist, dann führt der nächste defekte Block zum Datenverlust. Anschließend gibt es Schreib- und Lesefehler auf diesem Block. Es gibt im Grunde keinen fehlerfreien Flashspeicher. Die meisten Speicherbausteine haben bereits im Auslieferzustand defekte Blöcke.
Flash Speicher hat nur eine sehr begrenzte Anzahl verfügbarer Schreibzugriffe. Deshalb wird viel Aufwand getrieben, um die Schreibzugriffe aufs ganze Flash zu verteilen und nicht einzelne Blöcke zu überfordern (Wear Leveling). Es gibt extra Flash Filesysteme, die sich darum kümmern (ubifs oder jffs2). Bei Samsung kümmert sich der berühmte Flash Controller darum, deshalb kann man auch Filesysteme benutzen, die eigentlich nicht für den Flasheinsatz ausgelegt sind (ext4 oder FAT).

"Recovery Methode"?
Also man könnte ein neues PIT File flashen und dadurch per Odin umpartitionieren.

Ich kenne keine modifizierten PITs fürs Tab. Die Anleitung bei xda beschränkt sich auf parted.

Ein anderer Kernel könnte ja da trotzdem drauf booten, ohne diese Partition. Ins Recovery kann ich ja auch booten. Ist also zumindest denkbar, wäre die Frage, ob es dafür Kernel oder Recovery mit entsprechender Funktion gibt.

Ja, die wird es geben. ABER: Da wir seit ungefähr 2 Wochen wissen, dass der "Brick Bug" durch die ext4 Library der Custom Recoveries ausgelöst wird, wäre genau dieser Kernel und dieses Recovery die größte Gefahrenquelle für dein Tab. Sicher sind im Moment nur Samsung Stock Kernel und Stock Recovery - und damit geht es nicht.

Die eMMC-scan-scripte hatte ich eigentlich so verstanden, dass sie über die "update from zip" Funktion direkt aus dem Recovery gestartet werden können. Ist das überhaupt denkbar? Das Recovery müsste dazu vermutlich die entsprechende Scripting Basis bereitstellen (hab nicht genau verstanden, wie das gehen sollte).

Doch, das geht schon - zumindest ein Low Level Zugriff würde gehen. Die Frage ist, was es bringt.

Unterschiede zw. Note und Tab gibt es diesbezüglich ja wohl nicht, oder?

Was die Scripte angeht, nicht. Was die erforderliche Funktionsbasis im Recovery angeht, schon. Weil beim Tab Kernel und Recovery getrennt sind.

Und die "Zusammenfassung" im ersten Posting wäre nach Deiner Aussage ja dann falsch und es kommt irgendwo hinten (wieso verlinkst Du das dann ohne Hinweis darauf??).

??? Welchen Thread hast du gelesen? Gerade die Zusammenfassung im ersten Beitrag ist richtig. Die Auszüge aus dieser Zusammenfassung hab ich ja ein paar Beiträge weiter oben schon zitiert. Bei xda wird das alles in diesem Thread behandelt:
Discussion thread for /data EMMC lockup/corruption bug - xda-developers

Ich zitiere:

The nature of the problem is a call to the function make_ext4fs(). This function isn't provided by the kernel, rather it is provided as a library (libext4_utils.a) that is used when compiling Recovery and the update installer. It does end up eventually calling kernel mmc driver routines, which then trigger the EMMC firmware lockup/superbrick bug.

Aber genau das steht in dem Thread zur Brick Problematik hier im Forum, den ich oben verlinkt habe (halt nur auf Deutsch).

Threads haben halt die dumme Angewohnheit, dass die aktuellen Informationen am Ende stehen. Bevor man sich also nach Lesen von Beitrag 1 ans Ausprobieren macht, sollte man den Thread bis zu Ende lesen, ob nicht irgendwelchen neueren Erkenntnisse auftauchen. Das ist bei den Threads zur data.img der Fall, und bei der Brick Bug Ursache ebenso.

Bei den EFS Zugriffen hätte es gereicht, meine Flashanleitung zu lesen. In den weiteren Erläuterungen dazu habe ich das Problem damit erläutert. Vielleicht steht da nicht im Detail, warum ein EFS Zugriff problematisch ist, sondern nur, dass er problematisch ist. Warum ist aber auch egal, und die technische Erklärung würde wahrscheinlich eh jeden überfordern (wenn sie überhaupt bekannt ist. Ich kenne sie nicht). Wir müssen das alles mühselig per Reverse Engineering austüfteln, da Samsung uns nicht die Dokumentation für seinen EFS Zugriff zur Verfügung stellt. Und da niemand freiwillig sein Gerät zerstört, sind wir nun mal auf die Schilderungen angewiesen, wo es Leuten unfreiwillig passiert ist - mit allen Einschränkungen, die es in solchen Schilderungen von technische Laien gibt (das ist kein Vorwurf an die Leute, sonder schlicht und einfach nicht zu ändern. Es macht die Arbeit aber noch mühseliger, die essentiellen und reproduzierbaren Fakten daraus zu extrahieren). Dabei geschehen Fehler, und Erkenntnisse müssen korrigiert oder sogar revidiert werden. Wenn hier eine spezifische Frage auftaucht, kannst du sicher sein, dass der Antwortende nach bestem Wissen und Gewissen den aktuellen Stand der Erkenntnisse wiedergibt.

Fakt ist, dass hunderte zerstörte Geräte allein hier im Forum eindeutig belegen, dass die EFS Zugriffe gefährlich sind, wenn man eine Firmware mit falschen CSC flasht. Die Lösungen und Hinweise, wie man das Problem umgehen kann, sind hingegen ausführlich beschrieben. Wenn du es nun aufgrund dieser "dünnen" Informationslage nicht glaubst oder meinst, dich mit deinen Erfahrung darüber hinwegsetzen zu können, dann kannst du das natürlich machen. Niemand zwingt dich dazu, unsere Anleitungen zu befolgen. Aber erwarte nicht, dass wir den Karren für dich aus dem Dreck ziehen, wenn du dich ausschließlich dadurch profiliert hast, unsere Hinweise zu ignorieren oder anzuzweifeln.

Merke dir: Wir machen das nicht erst seit gestern, sondern seit Jahren. Wir wollen auch niemanden ärgern hier oder Informationen zurückhalten. Aber es sollte klar sein, dass wir nicht in jeder Antwort die komplette, über Monate aufgebaute Wissensbassis wiedergeben, die zu einer spezifischen Handlungs-Empfehlung führt. Dafür fehlt die Zeit, und 99,7% aller Leser interessiert das nicht. Die sind froh, wenn ihnen einer sagt "flashe die data.img nicht", und tun das einfach. Wenn du der Meinung bist, dass du diese Information brauchst, bevor eine Empfehlung sich dafür qualifiziert hat, von dir befolgt zu werden, dann hält dich niemand davon ab, die Suche zu benutzen und dir die Information zu holen. Aber eine Empfehlung: Lies die Threads bis zu Ende, um auf dem aktuellen Stand einer Entwicklung zu sein.

Wenn das stimmen sollte, wäre es ein himmelschreiender Programmierfehler von Samsung (oder Google?) und schon sehr komisch, wenn die sowas machen sollten.

Warum ist es ein Fehler, wenn ein Gerät einwandfrei funktioniert, solange man es sachgemäß im Sinne des Herstellers benutzt?

Noch mal: EFS geht erst kaputt, wenn du alle Anleitungen, Lizenzbedingungen und Vorgaben des Herstellers ignorierst; dir Tools aus dem Internet besorgst, die nicht für die Benutzung mit den Telefonen freigegeben sind und Firmware flasht, die nicht für das Gerät gedacht ist. Was kann man sonst noch falsch machen?
Und selbst dann kann man sein Gerät gefahrlos flashen, wenn man sich an die Anleitungen hält, die im Laufe der Zeit in der Community dafür entstanden sind. Dafür mussten viele Geräte dran glauben, bevor die Erkenntnisse gereift sind, aber mittlerweile weiß man es. Du kannst es gern nachlesen. Mit dem i9000 ging es los, vor über 2 Jahren. Die Anzahl der Beiträge zum EFS und IMEI Thema sollten irgendwo so zwischen 15.000 und 25.000 liegen. Da kannst du die komplette Historie der langsamen Erkenntnisgewinne nachvollziehen. Es ist alles noch da, nichts wurde gelöscht.

Du kannst aber auch einfach jemandem glauben, der vom ersten Tag an dabei war.

 

[pibach]

Danke Frank, ich kann schon verstehen, dass man nicht immer von Adam und Eva anfangen möchte, aber ich wollte einfach nur das Gerät wiederbeleben, da waren Deine Hinweise halt nicht zielführend, bisher kam (bis auf "Einschicken") ja keine einfache Handlungsanweisung. Und Manches ist halt nicht so plausibel bzw. nicht zu verstehen, wenn bestimmtest Hintergrundwissen fehlt. Mit dem data.img hat halt alles darauf hingedeutet, das zu "benutzen", was auch immer Deine Anmerkung "flashen geht nicht" in dem Zusammenhang sagen sollte. Soviel solltest Du doch auch mitbekommen haben. Oder? Das hat aber auch hier gar keine Relevanz gehabt, ist nur ein Beispiel für den etwas schwierigen Kommunikationsstil. Ich möchte mich dabei gar nicht beschweren, hab ja kein Anrecht auf "tollen Support" mag es aber auch nicht, wenn Du mich latent angreifst. Also einfach weglassen. Ok?

das mount /data Problem hat ja nun offenbar das Wipen mit der Android 3.2 Firmware behoben. Hab auch noch mal CWM 6.0.0.6 (ist wohl die aktuellste) installiert, das konnte auch erfolgreich wipen (mit abschließender Meldung). Kann nun /data mounten und unmounten, das scheint also jetzt ok. Demnach hat das schon mal nicht an einem "Brick" gelegen - allerdings schon komisch.

Komischer Weise kann ich sd card nicht mounten und auch formatieren in CWM meldet fehler can't mount sc card. Weiß nicht, ob das vorher auch schon so war (hab ich nicht drauf geachtet, in der Stock recovery gibt es dazu ja keine Optionen), eine Fehlermeldung diesbezüglich gab es jedenfalls nicht (nur eine für Mountproblem mit /data, die Medung krieg ich ja jetzt aber nicht mehr).

Doch, klar. Flashspeicher ist sogar recht empfindlich.... wear leveling

Beim wear leveling werden aber einfach defekte Blöcke durch den Controller ausgetauscht. Der Flashspeicher bleibt also funktionsfähig. Lebensdauern je Block liegen auch bei 10.000-100.000 Schreibzugriffen.

Ich kann schon verstehen, dass reverse Engeneering nicht so leicht zu ultimativen Erklärungen führt. Aber einfach so mal defekte Flashspeicher ist extrem unwahrscheinlich.

Ich kenne keine modifizierten PITs fürs Tab. Die Anleitung bei xda beschränkt sich auf parted.

in diesem Thread schreiben die auf xda: "I will not cover this method as hg42 already wrote a very detailed tutorial about this. This tutorial is about Galaxy Note but you can appIy it to our 7.7 and you'll find PITs for P6800 there. I will soon make pits for P6810 using the scripts provided in hg42's guide."
Also gibt es wohl entsprechend vorkonfigurierte PIT files, sodas man das leicht auch als Noob User umsetzen können müsste.
Wobei die auch schreiben, dass parted etc ginge auf dem Tab, scheint also doch einen ADB Modus zu beherrschen. Evtl. unterstützt das CWM? Mal ausprobieren...

... function make_ext4fs() ...

ja, das hatte ich gelesen.
Scheint dann ja aber Kernelfunktionen aufzurufen.
Liegt also wohl an dem Zusammenspiel, diese Funktion aufzurufen, den falsch parametriesierten Kernel und dem fehlerhaften eMMMC.
Die Zusammenfassung widerspricht Deiner Aussage in sofern, dass Du ja sagst, Stock Sachen (Kernel+Recovery) seien save. Und machen diesen Aufruf nur manche Custom Recoveries, und das Stock Recovery funktioniert also anders? Wäre ja komisch. So ganz klar ist das aber wohl niergendwo beschrieben, oder? Ursächlich an der Miesere wäre aber schon der Hersteller, bzw. der Stock ICS Kernel. Es kursieren ja auch Kernel, die den Brick Bug (des Stock Kernels) beheben sollten.

Fakt ist, dass hunderte zerstörte Geräte allein hier im Forum eindeutig belegen, dass die EFS Zugriffe gefährlich sind, wenn man eine Firmware mit falschen CSC flasht.

Ok, das ist zumindest erstmal eine Beobachtung. Ein anderer Fakt ist aber eben auch, dass es schon komisch ist, wenn das so programmiert sein sollte. Also ist das entweder gar nicht die tatsächliche Ursache. Oder eben ein herber Programmierfehler. Darüber müssen wir doch wirklich nicht diskutieren, oder?

Ansonsten ist auch unklar, warum bei korrupten EFS das Tab nicht bootet - eigentlich sollte es booten, Mobilfunknetz ist dann aber nicht einbuchbar. Und ob da dann noch was machbar ist oder nicht (per JTAG?) ist mir auch nicht klar geworden.

...und Firmware flasht, die nicht für das Gerät gedacht ist...

Naja. Das kann man eben sehr unterschiedlich sehen. Muss ich nicht wiederholen, oder?
Z.B. Umflashen von Schweizer HC auf Österreichische ICS war nun mal nötig, da ansonsten gar kein Update angeboten wurde.

Und selbst dann kann man sein Gerät gefahrlos flashen, wenn man sich an die Anleitungen sind, die im Laufe der Zeit in der Community dafür entstanden sind.

Hm. Weiß nicht genau.
Tritt der Brick Bug nun auch beim Stock Recovery auf, ja oder nein? Wer weiß das tatsächlich?
Und der "normale Flash Bug"?
Das Update auf das Custom Rom Nexness, nach dem bei mir dann kein Boot mehr möglich war, geschah auch nach Anleitung. Woran das nun gescheitern ist und was überhaupt der genaue Defekt ist - weiß ich immer noch nicht wirklich.

Der ursprüngliche Beitrag von 19:22 Uhr wurde um 20:14 Uhr ergänzt:

diese Diskussion hier bringt dich sowieso nicht weiter.

Mag sein. Kann ich nicht wirklich einschätzen.
Wäre von daher interessant, wieso Du glaubst, dass auser Einschicken nichts hilft. Hattest Du denn genau das selbe Problem? Und was hattest Du da konkret probiert?

Wenn es ein eMMC Brick sein sollte, müsste ja zumindest Repartitionieren gehen.
Erstmal wäre ja nun ein e2fsck (über adb) fällig. Dazu wäre es hilfreich zu wissen, wie. Auch lt. diesem Posting scheint das wohl native über CWM zu klappen.
Und in diesem Posting konnte e2fsck die Fehler sogar beheben.

Edit:
Die Symptome hier:

Symptome

• Du kommst in den Download mode (Odin Modus) und evtl in die recovery
• wenn du probierts, zu wipen (data) in der recovery, das Gerät 'hängt' oder bootet neu
• nach einem flash einer FW mit Odin, hast Du Probleme, obwohl bei Odin 'success' stand
• Odin bleibt beim flashen bei data.img oder factoryfs stehen

Original aus diesem Thread, bestehen (bzw. bestanden) ja genau auch bei meinem Tab.
Die fixen das durch Repartitionieren (per modifiziertes PIT und Odin flash).
Ob es ein eMMC Brick Bug ist oder "irgendein anderer Formatierungsfehler" des Flashspeichers wird da nicht so klar gesagt.

 

[frank_m]

Komischer Weise kann ich sd card nicht mounten und auch formatieren in CWM meldet fehler can't mount sc card.

SDCard und /data liegen beim Tab physikalisch im gleichen Speicher. Die SDCard ist beim Partitionslayout des Tabs (und auch bei den neueren Samsung Smartphones) ja nur ein virtueller Mountpoint in /data.
Die Frage ist, was CWM damit genau macht, und ob es darauf eingestellt ist. Wenn es das korrekt berücksichtigt, und trotzdem nicht auf die SDCard zugreifen kann, dann deutet das darauf hin, dass in /data was nicht stimmt.

Beim wear leveling werden aber einfach defekte Blöcke durch den Controller ausgetauscht. Der Flashspeicher bleibt also funktionsfähig.

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, die nachweisbar darauf zurückgingen (schon vor der Brick Bug Problematik).

ja, das hatte ich gelesen.
Scheint dann ja aber Kernelfunktionen aufzurufen.

Natürlich ruft es irgendwann eine Kernel Funktion auf. Das macht das Samsung Stock Recovery aber auch. Unterschied: Beim Stock Recovery passiert nichts, beim CWM gibt es ein erhebliches Risiko für den Brick Bug.

Und machen diesen Aufruf nur manche Custom Recoveries, und das Stock Recovery funktioniert also anders?

Ja, genau so ist es. Der Source Code für das Samsung Recovery ist ja nicht verfügbar, deshalb weiß man nicht, was die genau machen. CWM arbeitet anders und produziert auf den betroffenen Samsung Geräten den Brick Bug.

Es kursieren ja auch Kernel, die den Brick Bug (des Stock Kernels) beheben sollten.

Genau auf diese Aussage haben sich bis vor kurzem immer alle zurückgezogen. Inzwischen sieht das alles anders aus. Es ist erwiesen, dass das MMC_CAP_ERASE der Samsung ICS Kernel nicht ursächlich für das Problem verantwortlich ist, sondern bei richtiger Benutzung ungefährlich ist. Die Frage ist nun: Reicht dann tatsächlich das Deaktivieren dieser Funktion? Oder ist da was in make_ext4fs(), was auch bei deaktiviertem MMC_CAP_ERASE den Brick Bug erzeugen kann? Die Frage ist nicht eindeutig beantwortet, ich kenne die Antwort auch nicht. Die hohe Quote an Bricks beim Flashen von CM Firmwares (deren Kernel ja ohne MMC_CAP_ERASE arbeiten) hat mich ja vor 3 Monaten schon zu der Aussage hingerissen, dass diese Kernel offensichtlich nicht so sicher sind, wie immer alle behaupten, und statt dessen die Samsung Stock Kernel keine nennenswerten Probleme machen. Damals wusste ich noch nichts von den aktuellen Erkenntnissen, die Feststellung beruhte einfach auf den Schilderungen der Nutzer in den diversen Foren. Irgendwie passten die auftretenden Bricks einfach nicht mehr zur Erklärung, die bis dahin kursierte. Das musste selbst dem letzten Zweifeler auffallen. Zu der Aussage stehe ich auch heute noch. Ich würde momentan um nichts in der Welt aus einem CWM heraus einen Wipe ausführen. Egal mit welchem Kernel.

Ein anderer Fakt ist aber eben auch, dass es schon komisch ist, wenn das so programmiert sein sollte. Also ist das entweder gar nicht die tatsächliche Ursache. Oder eben ein herber Programmierfehler. Darüber müssen wir doch wirklich nicht diskutieren, oder?

Warum soll das ein Fehler sein? Der Fall kann ja nie vorkommen. Warum also sollte man von Samsung aus dort einen "Fehler" korrigieren, wenn durch die Update-Mechanismen sichergestellt ist, dass der "Fehlerfall" nie eintreten kann? Vielleicht ist die Funktion, die bei falscher Anwendung zum Fehler führt, bei richtiger Anwendung zuständig für essentielle Funktionen des EFS? Aber das ist eine rein akademische Diskussion.

Ansonsten ist auch unklar, warum bei korrupten EFS das Tab nicht bootet - eigentlich sollte es booten, Mobilfunknetz ist dann aber nicht einbuchbar.

Es sind ja nicht nur Informationen zur IMEI und zum Mobilfunknetz dort gespeichert. U.a. liegen da Infos zur Bluetooth Adresse, zum WLAN MAC und eben auch zum ProductCode. Vor allem die letzte Info wird bei jedem Boot ausgelesen, und auf dieser Basis werden ggf. Aktualisierungsscripte ausgeführt. Wenn die Infos im EFS fehlerhaft ist, kann der Bootvorgang scheitern.

Und ob da dann noch was machbar ist oder nicht (per JTAG?) ist mir auch nicht klar geworden.

Nach allen vorliegenden Erkenntnissen: Nein. Es gehört mehr dazu. Ich bin mir nichtmal sicher, ob die Samsung Service Center das korrigieren können, oder ob die einfach das Mainboard tauschen.

Naja. Das kann man eben sehr unterschiedlich sehen. Muss ich nicht wiederholen, oder?

Nein, das kann man nicht unterschiedlich sehen. Mit offiziellen Tools wärst du niemals in der Lage, diese Firmware auf dein Gerät zu kriegen.

Z.B. Umflashen von Schweizer HC auf Österreichische ICS war nun mal nötig, da ansonsten gar kein Update angeboten wurde.

Richtig, Samsung bietet kein Update an für den Product. Und dann besorgst du dir ein Update für andere Geräte und wunderst dich, wenn Dinge passieren, die du nicht willst?

Tritt der Brick Bug nun auch beim Stock Recovery auf, ja oder nein? Wer weiß das tatsächlich?

Nein, der Brick Bug - also die Zerstörung der Block-Zurordnung im Flash Controller - tritt mit Samsung Stock Software definitiv nicht auf.

Das Update auf das Custom Rom Nexness, nach dem bei mir dann kein Boot mehr möglich war, geschah auch nach Anleitung.

Ein Custom ROM mit einem angeblich sicheren Kernel, der kein MMC_CAP_ERASE verwendet, das aber während er Installation einen Wipe per CWM ausführt? Hhhhmmmmm .....

Woran das nun gescheitern ist und was überhaupt der genaue Defekt ist - weiß ich immer noch nicht wirklich.

Das werden wir vielleicht auch nie herausfinden.

Wenn es ein eMMC Brick sein sollte, müsste ja zumindest Repartitionieren gehen.

Wenn du die entsprechenden PIT Files findest, dann probiere es aus. Ganz ehrlich: Das würde mich auch brennend interessieren, was dabei herauskommt.

 

[pibach]

Genau auf diese Aussage haben sich bis vor kurzem immer alle zurückgezogen. Inzwischen sieht das alles anders aus. Es ist erwiesen, dass das MMC_CAP_ERASE der Samsung ICS Kernel nicht ursächlich für das Problem verantwortlich ist, sondern bei richtiger Benutzung ungefährlich ist. Die Frage ist nun: Reicht dann tatsächlich das Deaktivieren dieser Funktion? Oder ist da was in make_ext4fs(), was auch bei deaktiviertem MMC_CAP_ERASE den Brick Bug erzeugen kann? Die Frage ist nicht eindeutig beantwortet, ich kenne die Antwort auch nicht. Die hohe Quote an Bricks beim Flashen von CM Firmwares (deren Kernel ja ohne MMC_CAP_ERASE arbeiten) hat mich ja vor 3 Monaten schon zu der Aussage hingerissen, dass diese Kernel offensichtlich nicht so sicher sind, wie immer alle behaupten, und statt dessen die Samsung Stock Kernel keine nennenswerten Probleme machen. Damals wusste ich noch nichts von den aktuellen Erkenntnissen...

hm. Also dann steht Deine Schlussfolegrung aber im Widerspruch zu dem verlinkten Thread. Und eine wirkliche Begründung gibt es nicht. Richtig? Und was meinst Du mit aktuellen Erkenntnissen? Bisher wird der stock Kernel verdächtigt. Es wäre sehr wichtig klar festzustellen, welche Konfiguration nun "sicher" ist. Kannst Du dazu was verlinken? Oder ist das komplett strittig?
Ich hab ja nun auch viele male gewiped, weil das z.T. ja auch "empfohlen" wurde. Für diverse Dinge (u.a. Format /data) geht auch nur das neueste CWM 6.0.0.1. Ist das sicher? Da besteht nun doch ziemliche Verunsicherung. Hab auch einen als "sicher" eingestuften Kernel besorgt, bringt das dann überhaupt was?

Wenn du die entsprechenden PIT Files findest, dann probiere es aus. Ganz ehrlich: Das würde mich auch brennend interessieren, was dabei herauskommt.

Die PITfiles sind da gepostet. Es sind allerdings sehr sehr viele. Man muss also in etwas wissen, welcher Teil des Flash korrupt ist. Dafür mus man e2fck laufen lassen. Was ist denn nun mit meiner Frage dazu: geht adb aus dem Recovery heraus (besondere Einstellung gibt es dazu ja wohl nicht)? Weißt Du das? Ansonsten teste ich das mal....
Möglicherweise ist das aber auch meist der gleiche Speicherbereich, dazu hab ich aber noch keine Info gefunden, weiß also nicht, welches PITfile ich nutzen sollte.
Gibt in dem Tread aber ettliche Tab 7.7 User, die besttigen, dass sie Ihr GErät damit unbricked haben!

 

[frank_m]

hm. Also dann steht Deine Schlussfolegrung aber im Widerspruch zu dem verlinkten Thread.

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

Und was meinst Du mit aktuellen Erkenntnissen? Bisher wird der stock Kernel verdächtigt.

Nein, der Stock Kernel wird eben nicht mehr verdächtigt. Das Custom Recovery ist gefährlich. Genau das steht in dem verlinkten Thread.

Es wäre sehr wichtig klar festzustellen, welche Konfiguration nun "sicher" ist. Kannst Du dazu was verlinken?

Siehe den verlinkten xda Thread und auch die hier aus dem Forum: Der Stock Kernel mit Stock Recovery ist eindeutig sicher! Da gibt es überhaupt keinen Zweifel.
Erst wenn ein Custom Recovery ins Spiel kommt, wird es gefährlich. Welche Kernel mit dem Custom Recovery gefährlich sind, ist zwar noch nicht zu 100% klar. Im Zweifel würde ich erst mal sagen: Alle, solange das Gegenteil nicht bewiesen ist.

Ich hab ja nun auch viele male gewiped, weil das z.T. ja auch "empfohlen" wurde. Für diverse Dinge (u.a. Format /data) geht auch nur das neueste CWM 6.0.0.1. Ist das sicher?

Nein, das ist definitiv nicht sicher. Das ist sogar extrem gefährlich, da es die fragliche make_ext4fs() benutzt.

Was ist denn nun mit meiner Frage dazu: geht adb aus dem Recovery heraus (besondere Einstellung gibt es dazu ja wohl nicht)?

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). Ich hab keine Ahnung, ob jemand ein Recovery gebaut hat, dass ADB ohne USB Debugging aktiviert. Probiere es aus.

Gibt in dem Tread aber ettliche Tab 7.7 User, die besttigen, dass sie Ihr GErät damit unbricked haben!

Wenn es tatsächlich der Brick Bug ist, dann wird das so sein.