Probleme mit ubifs

1. offizieller Beitrag

    Nachdem wir jetzt seit ein paar Tagen bei uns im Board über Probleme im Zusammenhang mit dem neuen ubifs gesprochen haben, wende ich mich mal direkt an das DMM Board. LukaNoah und ich haben seit dem Update mit unseren Boxen, beim intensiven Skinnen (ständiges Neustarten von enigma2), nach sehr kurzer Zeit Probleme mit dem Dateisystem. Zunächst verschwinden Einträge und Einstellungen (0 byte files). Danach, so war es zumindest bei mir, führte die Box nach jedem Deep Standby eine komplette Neueinrichtung der Box durch. Flashen über webinterface war nicht mehr möglich und ich musste die Box mit DreamUp und sectoren recovery flashen. Dies habe ich innerhalb von 2 Tagen zwei mal durch geführt und jedesmal wurden kaputte Sektoren gemeldet. Meine 7020HD ist 10 Monate alt, also sicher noch keine Altersschwäche :winking_face:


    Da jetzt auch andere bei uns Problem meldeten, wende ich mich mal direkt an das Board und die DEVS, um zu hinterfragen, ob das Problem bekannt ist?


    VG


    Ricardo22

    2 Mal editiert, zuletzt von Ricardo22 ()

    Also ich kann jetzt natürlich nicht für alle anderen im Board sprechen, die Probleme haben. Also ich habe seit dem Aufspielen des Images mit ubifs zwei Hardresets gemacht, da die Box fest hing.

    Also aus
    meiner Sicht kommt das vom Hardreset...

    Ich bastle auch viel..... ständig „reboot“ oder init 4... warten.... init 3..... kein Problem...



    Einmal nen Hardreset (Töchterchen hat den Schalter gefunden) und die Settings waren Ade..





    Grüße

    --
    openwrt + minicom + screen = 24/7 Bootlog

    • Offizieller Beitrag

    Hi,


    ja also ubi/ubfis ist nicht soo crash resistent wie jffs2. Also da können schneller mal Dateien kaputt gehen oder nur halb geschrieben werden wenn man einfach den Hauptschaltet betätigt.


    Aber das sollte keinen Einfluss auf den normalen Betrieb haben. Alternativ könnte man wohl ubifs mit der "sync" option mounten beim booten. Dann würden Dateien und Meta Daten immer direkt geschrieben. Das wäre in etwa dann das verhalten von JFFS2. Allerdings wäre damit vermutlich dann auch der Geschwindigkeitsgewinn wieder hin. Das ganze kann man so auch in der MTD FAQ zu UBI/UBIFS nachlesen.


    cya

    Ich stimme Dir zu, dass das Reseten per Hardreset natürlich für das Filesystem einen kleinen GAU bedeutet. Trotzdem kann das natürlich vorkommen und sollte ein Dateisystem nicht so zerschießen.


    Diese Dinge sind ja auch bei den Vorgänger-Images durchaus mal vorgekommen, ohne das derartig massive Fehler auftraten. Wie ich schon schrieb, es sind einige von uns im Board, die über diese "neuen" Symptome klagen. Deshalb wäre es wichtig für uns, ob dies als Problem bekannt ist. Ich skinne wieder mit dem alten Dateisystem, da es sich zumindest in meinem Fall als deutlich robuster darstellt.

    Schnello


    das Problem war bei mir, das ja jedesmal nach einem Deep Standby, eine komplette Neuinstallation ablief. Das bedeutet, vermute ich mal, das er versucht die Informationen wiederum in die schadhaften Sektoren zu schreiben. Also scheinbar nicht clever genug zu erkennen, dass er diese als schadhaft markieren müsste. Bin Laie, bitte um Verzeihung falls ich mich schlecht ausdrücke.

    Naja, normalerweise nutzt man ja den netzschalter der box eh nicht, außer vielleicht wenn die box eh im standby(deep standby) ist.
    Beim skinnen killed man e2 am besten gleich mit init 5 und startet es dann immer wieder mit "/bin/sh /usr/bin/enigma2.sh".

    • Offizieller Beitrag

    Hi,


    sag doch mal genau, wann es nun passiert / passieren soll. Bei einem normalen runterfahren der Box.... oder nur wenn man die Box einfach so hart abschaltet.


    Also im Normalbetrieb sollte nichts kaputt gehen. Und auch nicht wenn man die Box dann übers Menü sauber runterfährt. Wie schon geschrieben ist es wohl eher ein Problem wenn man einfach den Strom abschaltet.


    cu

    Ghost


    Also das Runterfahren per Netzschalter ist nicht meine bevorzugte Methode. :winking_face:
    Ist vielleicht in den letzten 2 Monaten zwei mal vor gekommen. Nein, diese Fehler schleichen sich während des "normalen" Betriebes ein. Was heißt schon "normal" beim skinnen :winking_face: Ich starte halt ständig enigma2 neu, um die Veränderungen zu begutachten.


    Diese Fehler scheint den normalen User nicht zu betreffen, sondern nur unter verschärften Bedingungen aufzutreten. Platzhirsch, LukaNoah, Ketschuss (Skinner und Betatester) haben diese Nachteile seit ubifs auch bemerkt.....

    Ich würde da nicht inbedingt gleich mit sync mounten, weil wenn das filesystem regelmässig seine Sachen rausschreibt kann ubifs sehr wohl auch recovern. Das problem ist das defaultmässig die Journal size mit der Flashgröße steigt und daher gerade auf der 7020 schon relativ groß ist, was implizit heisst das es schon selten rausgeschrieben wird.


    Macht mal einen einfachen Test - gebt sync in telnet ein und dann dreht nach ein Paar Sekunden die box mit dem Stromschalter ab. Das könnt Ihr 20x hintereinander mache und sie wird jedesmal booten. Macht es ohne sync und das wird 1-2x nicht gut ausgehen.


    Ich teste gerade das ubifs booten mit block2mtd von USB/SATA und da ist die box noch empfindlicher auf solche Sachen weil auch noch der Filesystemcache des fielsystems wo das ubifs file drinnen liegt mitspielt.


    Das ofter gesynced wird kann man dem Linux aber relativ leicht beibringen weil es dafür entsprechende Parameter gibt :smiling_face:


    Und zu dem Problem das im umountfs script ein sync fehlt um sicherzugehen das beim Deepstandby alles sauber rausgeschrieben wird habe ich vor fast 2 jahren schon einen Request geschrieben der ignoriert wurde ... vielleicht wäre jetzt der zeitpunkt gekommen den abzuarbeiten ...


    LG


    gutemine

    Soweit ich das bei uns im Board überblicke die 7020HD. Ich vermute es hat mit der Vergrößerung des nutzbaren Speichers zu tun. Vielleicht potenzieren sich dadurch auch die Fehlermöglichkeiten.
    Bei anderen Boxen habe ich jedenfalls noch nicht von Problemen durch ubifs gehört.

    • Offizieller Beitrag

    Hi,


    kann man das ganze denn irgendwie mal eingrenzen .. also welche Dateien kaputt gehen?


    Ich hab da gerade so gar keine Idee wie man da mal vorgehen könnte. Also mit dem sync wird das nichts zu tun haben.


    Beim normalen runterfahren wird das rootfs ja richtig ausgehängt. Das sieht man sogar in den debug ausgaben. Und dabei muss es auf jedenfall leer geschrieben werden.


    Also ein erster Ansatz wäre mal irgendwie zu versuchen einen Weg zu finden das zu reproduzieren und mal festzustellen welche Dateien kaputt gehen.


    cya

    Also das sync im umountfs script kannst du dir auch von hand rein machen und berichten ob die box dann bei normalem runterfahren noch das problem hat :face_with_tongue:

    • Offizieller Beitrag

    Hi,


    Ricardo22: hmm wann passiert das denn z.b. .. also dass du die e2 Einstellungen neu machen musst? Passiert das denn einfach so während des Betriebes der Box? Also quasi nur e2 einmal gekillt?


    Also wie gehst Du denn überhaupt beim skinnen vor?


    Also sinnvoll wäre es wie ja schon jemand geschrieben hat eine telnet session oder ssh öffnen. Dort "init 5" ... und dann enigma2 direkt im telnet starten mit enigma2.sh.


    Allerdings nach dem Init 5 ne weile warten.. dass e2 wirklich beendet ist. Und wenn du dann e2 beenden willst weil du am skin was geändert hast oder dergleichen.. dann einfach Strg-C drücken in dem ssh/telnet Fenster.


    Das wäre der einfachste und sinnvollste Weg beim skinnen. Denke ich.


    Wenn du dann irgendwann später e2 wieder normal benutzen willst ohne telnet/ssh session. Dann einfach wieder "init 3" eingeben.


    cu

    das root ist nicht umountable, deswegen ja der read only mount der implizit auch ein sync macht, aber nur wenn vorher schon ein sync war dann kommt es nicht zurück bevor das fertig ist, sonst schon und das kann eben das problem triggern. Aber das diskutieren wir besser im anderen Thread sonst wird es zu verwirrend weil das 2 verschiedene Probleme sind.