Dann ist eigentlich nicht das ubifs direkt dran schuld

Lies mal was dazu in den FAQ des ubifs steht:

http://www.linux-mtd.infradead…q/ubifs.html#L_empty_file

Und nachdem du nur 'defekt' sagst und weder ob das file weg, leer oder verstümmelt ist wirst du wohl etwas mehr dazu beitragen müssen um das problem in den Griff zu bekommen.

Verwendest du irgend ein Plugin das die keymap.xml verändert und evt. vergisst den filepointer zuzumachen, oder hast es gar selbst mit einem Editor geöffent. Evt. mal das lsofs binary benutzen um das zu überprüfen, etc.

Mach evt. mal das compression attribute bei der keymap.xml weg. Wenn du sie ständig editerst macht das eh nur begrenzt Sinn und sobald es unkomprimiert abgespeichert wird ist die chance auf corruption immer kleiner.

chattr -c /usr/share/enigma2/keymap.xml

Sry, wenn ich schon wieder meckern muß - aber:

Zitat

Zero-length files are a special case of corruption which happens when
an application first truncates a file, then updates it. The truncation is
synchronous in UBIFS, so it is written to the media straight away. But
when the data are written, they go to the page cache, not to the flash media.
So when an unclean reboot happens, the file becomes empty (truncated) because
the data are lost.

Alles anzeigen

Du willst mir jetzt aber nicht erzählen, daß jemand das versteht, der (beispielsweise) schon Probleme hat ein telnet-Fenster zu öffnen...
Bitte last mal die Kirche etwas im Dorf...

Ich will ja auch nicht das Ihr das auswendig lernt

Und es muss sich keiner für Kritik entschuldigen (schon wiel ich nichts für die technische Formulierung im Wiki kann).

Es ist halt nur so das ubifs manche Fälle anders handhabt, wodurch bei Applikationen die unsauber sind man ein File leichter leer machen kann also bei jffs2.

Wobei das hier gar nicht der Fall sein muss, aber ich habe auch genau geschrieben was er machen soll - mit lsof nachsehen ob nicht die keymap ständig als file geöffnet bleibt, was eigentlich ein einfaches Unterfangen ist.

Ich habe das übrigens auch schon geschafft und mich dann z.B. gewundert warum Dumbo ein device nicht umounten konnte um es zu formatieren bis ich nachgesehen habe und gemerkt habe das ich ein f.close() vegessen hatte.

Letztendlich ist das Problem das mit file kaputt eigentlich keiner was anfangen kann, sondern mehr und detailiertere Infos nötig sind, um das Problem einzugrenzen. Da sich der bad block count nicht verändert hat wissen wir jetzt z.B das es eher nicht am Bad Block handling vom ubifs liegen wird.

Ja

Was ich meinte, war, daß der etwas ahnungslosere User (NICHT dumm, sondern von der Materie halt keine Ahnung - ich kann ja auch keine Zugposaune spielen...) spätestens bei filepointer schon nur noch Bahnhof Bahnhof sieht, dann noch das wiki dazu anschaut... *würg*

vlt muß man doch etwas mehr vorkauen - mal eine telnet eingabe hinschreiben oder sowas - daß auch ein oben genannter User mal helfen kann und nicht erst 20 manpages lesen muß, damit er was rausbringt... nicht jeder hat da die Lust und Zeit zu... oder weis, was eine manpage ist...

Tja was spräche dagegen wenn du als bekennender Nicht-Posaunspieler das machen würdest ?

Z.B. raussuchen das es das lsof binary als ipk bei OoZooN im Board gibt, das man es wie jedes ipk installiert und wenn man lsof eingibt dann eine Liste aller geöffneten Files bekommt die man entweder von Hand nach der keymap.xml absuchen kann oder hat mit grep durchsucht:

lsof | grep keymap.xml

Oder halt andere filenamen die man schon verloren hat ...

All das wäre durchaus im Bereich des Möglichen ... auch für Nicht-Posaunespieler

Und ein mount -o remount,sync / in telnet nach dem booten kann man ja auch mal probieren ... ich habe schließlich Stunden damit verbraucht im rambo auszuprobieren wann man sync und wann man async mounten muss damit das root Filesystem auch mit ubifs nicht hops geht obwohl es ein file in ext4 ist, da könnt Ihr durchaus auch was beitragen. Sobald die box gebootet ist uns wenn man nicht gerade einen Softwareupgrade macht wo viel geschrieben ist ist es ziemlich egal ob man sync gemountet ist weil eh 98,72% nur lesend aufs Filsystem zugegriffen wird.

LG
gutemine

Ich bin immer noch blöde, aber ich gebe das zu und schäme mich einfach nicht dafür, sondern mache die Sachen trotzdem - wo ist das Problem dabei ?

Wer nichts macht macht zwar keine Fehler, aber er macht dann eben auch nichts.

Nur aus Fehlern lernt man, und wie schon gesagt wenn man genug Probleme ausschließt bleibt nur die Lösung über.

Und ja ich bin schon so alt das ich noch weis wie Methusalix seine Rezepte von Hand schreiben musste ...

Nur zur Info - ich habe auch noch Jumper gesteckt und die Soundkarte händisch in die autoexec.bat eingetrage.

Auf den Boxen, die ich besitze, habe ich das Problem nicht - und ich werde mir auch keine kaufen, nur daß ich das Problem habe...

Das ist einzig und allein ein Vorschlag, der sich aus meinem Boardalltag ergibt - und da keiner was postet, habe ich es halt mal hingeschrieben.

Bevor es in eine Grundsatzdiskussion ausartet - einfach ignorieren

Bei nicht beschreibbar geöffneten Files ist ubifs aber eigentlich nicht anfällig für solche Sachen.

Bitte schaue mal wie vorgeschlagen mit dem lsof nach und probier evt. auch das synchon rmeounten aus ob es dann auch noch passiert.

Du hattest dazwischen aber nicht evt. einen Softwareupdate ohne reboot gemacht der eine neue keymap.xml geschrieben hat ?

This is NOT the Marsu support thread, and as now dFlash supports UBIFS backups it is NOT the proper method for Migration anymore.

And as already explained any images > 128MB are NOT flashable with the bios anymore. You can probably flash them with dFlash by switching to nandwrite as the Flashtool, BUT again all these infos you find in the proper support threads.

Und bezüglich der settings datei - wenn du beim Skinnen irgendwann zu heftig das enigma2 mit mehrmaligem CTRL+C abbrichst werden sowohl timer, als auch epg oder settings evt. nicht sauber geschrieben, weil du wahrscheinlich während sie zum Schreiben geöffnet sind den prozess killst. Und da beschreibt das FAQ zum ubifs eben genau wie es sich in dem Fall verhält.

Das mag zwar anders sein wie beim jffs2 aber eben nicht falsch. Wenn du so arbeitest das dies immer wieder passieren kann entweder die root synchron mounten, oder besser gar nicht im Flash haben sondern vom stick booten, weil bei ext4 für das root filesystem kann das nicht passieren.

Ich würde aber sowieso niemals im Flash skinnen, weil wenn du dir das kaputt machst und du dir dann nur mit neuflashen helfen kannnst sind alle Änderungem an Skinn weg, das kann dir wenn du in einem Multiboot image skinnst nicht passieren, weil du dann halt vom Flash bootest und gemütlich die skinnprobleme im imagedirectory bereinigen kannst.

Ratschläge kann man nehmen oder nicht

Sagen wir mal so - im aktuellen dFlash kannst du für jedes ubifs Image auch jffs2 zum Sichern nehmen und das Ergebnis flashen.

Und du musst das Verhältnis zwischen Usern und Entwicklern sehen, nur weil Letzterem was nicht gefällt heisst es nicht das es den anderen nicht was bringt.

Die UBIFS Entwickler haben das nicht umsonst in Ihren FAQ weil die Frage immer wieder hochpoppt, insofern seit Ihr in guter Gesellschaft.

Ich kann aber damit leben wenn ich weis warum das so ist und was man dagegen tun kann.

Und im aktuellen enigma2 funktioniert das ja auch längst nicht mehr wie gewohnt, weil wenn du nicht behutsam wartest bis nach dem CTRL+C gestopped wird bleibt dir memory über und das enigma2 zeigt dir einen Liebevollen Crash wenn du es sofort wieder aufrufst,...

Und ich hätte auch gerne das dies so wie früher wäre, aber auch das werde ich wohl nicht bekommen.