>> ubifs_read_node: bad node type (255 but expected 1)

Das heisst das im recovery.c vom ubifs Treiber ein node 'recovered' wurde (also FF reingeschrieben) der scheinbar noch benutzt/referenziert wird.

Im Prinzip ist dies das 'alte' Problem und die Frage ist halt immer wie heftig es auftritt und wie viele Files betroffen sind und ob diese wichtig sind, weswegen es dir wahrscheinlich 'anders' vorkommt. Solange mit dem sync Flag das ubifs recovery geknebelt war, ist es halt viel öfter aufgetreten.

Meines Erachtens nach stimmt da irgendwas im subpage handling im Broadcom nand Driver nicht das 'zu viel/weit' recovered wird, aber da ich das Problem erst ein einziges mal hatte kann ich da sehr wenig dazu beitragen, schon weil man zum debuggen das ubifs Debugging inklusive debugfs im kernel aufdrehen müsste um entsprechenden Infos zu bekommen ob es wirklich an der vermuteten Stelle und warum passiert.

Vielleicht solltest Du mal überlegen das DarkShadow Plugin zu verwenden, das habe ich eigentlich dafür gemacht damit man in so einem Fall nicht wieder neuflashen muss. So eine Schattenkopie dauert beim ersten mal 30 Sekunden und dann nur mehr rund 10-15 Sekunden und wenn was schief geht hat man in data eine Kopie des rootfs die man leicht booten und von der man dann auch das rootfs wiederherstellen kann.

Letztendlich ist es zwar keine Lösung, aber man sieht das ganze dann viel entspannter

Wobei das nur meine persönliche & völlig inkompetente Sicht der Dinge ist

LG
gutemine

Sichern bringt da eigentlich niemandem was, weil korrupte Files nicht gesichert würden und selbst das nanddump würde da wenig helfen.

Es ist ja nicht so das man das Problem nicht reproduzieren kann, du musst nur ein großes file im Flash anlegen und wieder löschen und dabei die box abdrehen, wenn du das ein paar mal machst wird es wahrscheinlich bald wieder auftreten. Das Problem ist das ubifs eigentlich was das recovery angeht verdammt stabil ist, aber scheinbar macht eben genau diese recovery Routine hier das Problem - weil das ist der einzige Platz im code wo FF (also die in der Fehlermeldung genannten 255) in den Flash geschrieben werden um Blöcke wieder als unbenutzt zu markieren. Die Formel was und wie weit recovered wird ist aber mehr als ausgiebig getestet, also muss einer der Parameter den sie benutzt falsch sein damit es zu viele FF schreibt und in einen eigentlich gesunden inode reinrutscht. Und die Parameter kriegt der ubi Treiber eben vom Treiber für die Nandflash Bausteine. Aber den Fehler siehst du wahrscheinlich nur bei enabeltem Debug Output in den Treibern und im Console Log, für Normaluser ist das praktisch unmöglich das zu machen um sinnvollen Input zu liefern.

Wenn das so einfach zu finden wäre wäre es wahrscheinlich längst gefixed. Nachdem aber die 7020hd v2 mit den 4k großen Flashbausteinen am stärksten betroffen war (wo halt auch die writesize am größten ist) war es dort auch am leichtesten das Problem zu kriegen.

Aber wie schon gesagt, ich bin eigentlich inkompetent für solche Sachen

LG

gutemine

Du kannst mit dFlash auch als jffs2 sichern, aber die bootzeiten bei 1GB Flash sind dann ... gewöhnungsbedürftig.

Kleinen 2GB Stick an die Box machen und Flodder hilft auch, wobei auch das ext4 Filesystem Mucken machen kann, aber dort gibt es halt die Möglichkeit des Filesystemchecks.

Aber Nochmals, da in den 1GB Flash locker einen zweite Kopie des ganzen rootfs reinpasst und sich das data volume dafür anbietet macht das DarkShadow Plugin das recovern eingentlich ganz leicht. das schlimmtste was passieren kann ist das man die kernel command line umstellt (oder enabelt) und innerhalb von einer Minute bootet es wieder.

Jeder doofe Windows OEM PC hat heutzutage eine Recovery Partition, das Darkshadow macht im Prinzip auch nichts anderes, und da es eine Kopie des ganzen root filesystem ist verliert man normalerweise höchstens die aktuellen Timer, und das ist wohl zu verschmerzen.

Ich hätte noch eine nettere Variante in der Hinterhand wo sowas ähnliches wie Freeze verwendet wird um das ursprüngliche rootfs zu schützen (das ist dann nur mehr read only gemountet und kann dadurch nicht kaputt gehen), und alles delta in der data Partition landet, aber man soll seine User nicht überfordern

Nicht alle meine Bastelarbeiten sind halt Alltagstauglich ...