Kurze Erklärung zu der Bad Block Geschichte:

Das Problem ist dass viele weil es so bequem ist mit dFlash und damit mit dem writenfi Flashen und weil das keine neuen Bad blocks erkennen und markieren kann wird dann so ein unmarkierter Bad Block benutzt bis es schief geht. Der entsprechende Disclaimer ist ja nicht umsonst im Plugin drinnen, nur wird der halt ignoriert bis es schief geht. Und dann ist DreamUp mit Receover Bad sectors halt eine einfache Methode das ein solcher neuer Bad block erkannt und markiert wird und dann geht wieder alles wie vorher.

Ich muss mir eh mal überlegen ob ich das writenfi nicht aufbohre das es auch Bad Blocks kann (ist dann halt langsamer weil es schreiben und lesen muss um zu checken). Andererseits macht bei den heutigen Imagegrößen das writenfi badl eh keinen Sinn mehr weil Ihm ab 128MB nfi Größe sowieso das Memory ausgeht, und dann geht es sowieso nur mehr mit nandwrite zu Flashen das einfach das File sequentiell in den Flash schreibt ohne soviel Memory zu allozieren.

Wenn man mit nadnwrite Flasht das sehr wohl auch neue Bad Blocks markieren kann passiert das ja nicht, also werde ich wahrscheinlich komplett darauf umsteigen oder das
ubiformat /dev/mtd3 -f ubi.img
zum Flashen verwenden (was ja eigentlich die supportete Methode zum Flashen bei ubifs wäre).

Und ich beschwere mich auch nicht deswegen, das writenfi ist halt nur für den Loader gedacht, das wir es für ganze Images missbrauchen ist ja nicht Eure Schuld.

Aber das hat nicht wirklich was mit dem ubifs Problem zu tun, ich will das nur nicht im Raum stehen lassen ohne den Hintergrund zu erklären.

LG
gutemine

Ja das weis ich, aber es werden nicht ständig alle bad blocks gescanned, womit die Treiber erst draufkommen wenn sie was schreiben.

Deswegen habe ich ja gesagt man sollte wenn files verschwinden schauen ob plötzlich die Bad Block Anzahl sprunghaft ansteigt, dann wäre es möglich das etwas passiert was nicht sollte. Wenn das gleich bleibt dann bitte woanders weitersuchen

Ähm ich denke genau so ist es implementiert, deswegen musste man ja diese zusätzliche Einstellung dazu machen wenn mal falsch markiert wurde.

Ich habe mir das mal zu Forschungfszwecken nachgebaut - sprich ein kleines Programm das dir gute Blocks als Bad markiert und das auch wieder rückgängig machen kann, inklusive entsprechenden Test ob der block auch OK ist.

Ich kann dir so hübsche Muster an Bad Blocks in den Flash machen oder auch den gesamten Freespace deinens Flash als Bad markieren, etc...

Die codebasis dafür findest du in den mtdutils bzw. im nand_check das ich auf die Dreambox portiert habe.

Das eigentliche Problem ist das du bei laufendem gemountetem Filesystem das nicht so einfach machen kannst und man entweder vom USB stick booten muss oder es eben im Bios oder in einem initramfs machen muss bevor das root filesystem gemountet wird

ubifs macht sich das handling der Bad blocks aber selber, akzeptiert aber natürlich bereits als bad markierte blocks.

Insofern ist aber eigentlich alles schon da was nötig ist und im Prinzip funktioniert es auch, mit der Einschränkung vom writenfi und damit dem dFlash die ich versucht habe zu erklären.

Was ich noch machen könnte WENN Interesse daran besteht ist ein auf nandwrite basierendes Flashtool schreiben das unser nfi format versteht.

Den C++ code zum rausholen der jeweiligen jffs2 und ubifs images bzw. dem ssl habe ich ja fertig im nfidump, wenn ich mit writenfi flashe benutze ich das ja um die 3 files rauszuholen und dann mit dem writenfi binary zu schreiben.

Das writenfi von einem standalone binary zu einer Routine zu machen und zum nfidump dazu zu linken das es ein einzige Binary ist wäre in wenigen Stunden erledigt.

ABER das ist dann trotzdem von DMM nicht supportet, obwohl es das Memory Problem des writenfi lösen würde UND du dann beliebig große Images flashen könntest UND mit nandwrite das Industriestandardtool zum Flashen verwenden würde.

EDIT: Ich habe im Developer Bereich dazu einen eigenen Thread aufgemacht weil das nicht hier hergehört und nur weiter verwirrt.

LG
gutemine

Wenn du diese ganze Funktionalität ins Bios packen willst wo du ja kein Betriebsystem und auch nicht Treiber für alle devices hast wird das ziemlich mühsam. Sachen wie das Lablmounten das nur 1 halbe Codeseite ist da reinzumachen oder eben Dinge wie grub oder uboot sie könnten sind nun mal nicht vergleichbar. Insofern muss ich da DMM auch in Schutz nehmen vor Euren Wünschen.

Und du denkst zu kompliziert, wenn die vorhandenen kernel Optionen ausreichen das du von einem stick oder SATA bootest dann brauch ich doch nicht das Bios um den zu befüllen oder zu flashen. Mit Block2mtd kann ich das Image praktisch direkt booten, sogar vom rawdevice eines sticks wenn es sein muss. Ein Tool um es dort drauf zu schreiben muss dann aber nicht im Bios sein.

Aber bitte diskutiert das im nand(nf)write Thread, ich habe den ja nicht umsonst aufgemacht, weil das nichts mit den ubifs Problemen zu tun hat.

LG
gutemine

Und noch kurz was dazu warum das bad Blocks oft hilft, wobei ich da bei der Formulierung aufpassen muss:

Sagen wir mal so - gewisse binaries (zu denen auch der SSL und die Treiber und auch enigma2 gehört) checken ihre Integrität, sprich ob sie gepatched wurden.

Der check geht aber 'möglicherweise' nicht gut aus wenn was unmarkiertes Korruptes mitgezählt wird oder wenn unbenutzte Bad blocks falsche Checksums haben, etc.

Nur beim Recover Bad blocks werden aber ALLE Blocks sauber gelesen geschrieben und nochmals gelesen womit dann diese binaries wieder glücklich sind und die box wieder bootet, oder zu crashen aufhört, ...

Und bitte nicht weiter nachfragen - mehr an Infos dazu wird Euch auch DMM denke ich nicht geben.

Und nein, DAS ist keine urbane Legende.

Versuchen kann man immer. aber in den Fällen um die es hier geht wird es wahrscheinlich nichts helfen.

Ich habe gesagt das ich dazu keine Fragen beantworten werde, aber Ihr sollte auch nicht Sachen rein interpretieren.

Und im OE 2.0 funktioniert das eigentlich ganz gut, wenn man von den kopierten Security Chips absieht ...

Ich versteh das ganze Problem hier nicht.

Ich machen jeden Tag zwischen 50 und 100 E2 Neustarts (alle über FB), und hab ausser selbstgemachten GreenScreens noch keine Probleme gehabt.

Allerdings benutze ich auch das DMM Experimental Image, oder ich hab die "eine" Box

"Eine Box, sie zu knechten, sie alle zu finden, Ins Dunkel zu treiben und ewig zu binden"

Schlechte Rethorik, weil mit DRM hat das 0 zu tun

Und ja ich malträtiere meine Boxen auch recht heftig und das ubifs macht das genauso gut mit wie das jffs2.

Mal sehen ob es von einem blockdevice genauso gut geht, weil das rambo 0.10 ist gerade zum Testen fertiggeworden, da macht ubigfs auf den kleinen Boxen plötzlich wieder Spass auch wenn es noch etwas umständlich ist

Zum eigentlichen Problem denke ich schon, aber ohne verwertbare Inputs wie logs ist das auch für sie schwer.