UBIFS sudden death

  • Hi,


    ich les grade noch amüsiert ein paar Threads, wo sich jemand beim Flashen kompliziert anstellt und spiele nebenbei die aktuellen Updates auf meiner 7020HD ein. Und dann das:


    Wie man sich denken kann, ist nach einem Rückfall auf R/O nicht mehr viel los mit dem Root-FS, E2 ist in Dauer-Crash-Restart-Schleife und der Balken im Display bleibt bei 50% stehen. Das wird auch bei einem Reboot nicht besser, der Fehler im UBIFS geht nicht von selbst weg. Big baddaboom.


    Also das letzte dflash-Backup eingespielt und die Box läuft wieder. Diesmal lief es dann auch nach den Updates problemlos weiter. So richtig robust wirkt der Umgang mit dem Flash durch UBI(FS) dann aber immer noch nicht. Und mein Verdacht wurde leider auch bestätigt:
    Vorher:

    Code
    UBI: max/mean erase counter: 36/2


    Nachher:

    Code
    UBI: max/mean erase counter: 0/0


    Flashen mit dem SSL ist nicht UBI-aware und zerstört die komplette EC-Statistik. Der PEB mit 36 Erases ist jetzt ununterscheidbar von denen, die nur ein oder zwei Erases hatten. Fühlt sich nicht so an, als würde da auf Dauer durch UBI ein Wear Leveling stattfinden, wenn man öfter mal komplett neu flasht. Updates einspielen sollte besser laufen, aber wie man sehen kann, ist da UBI kein Grund, dass es einem nicht um die Ohren fliegen könnte. Hässlich: Wenn man die EC-Statistik am dringendsten bräuchte, geht sie verloren...


    Andre.

  • Hatte gestern auf meiner DM7020 selbiges Problem. Beim Hochfahren ging nichts mehr, Endlosschleife. Musste auch ein Backuo zurück spielen.

  • Das hatte ich am 1 September, wollte auch nur kurz die Updates vom 31.08. auf meine DM7020 einspielen und dann hatte ich auch die Endlos Bootschleife :smiling_face_with_horns:


    Aber dank dflash war das kein großes Problem, Backup geflasht dann noch mal die Updates gemacht und siehe da, beim zweitem Mal hat alles ohne Problem geklappt.


    Man kann sich eigentlich gar nicht genug bei gutemine bedanken, ohne dflash wäre das alles viel problematischer :winking_face:

    DANKE für Eure Hilfe !


    DMM Experimental + GP3

  • Hi,


    kann mal jemand versuchen wenn er das Problem nochmal hat sich per telnet auf der Box einzuloggen und dann

    Code
    mount -o remount,rw /

    eingeben. Laut UBI/UBIFS FAQ soll sich das filesystem beim remounten versuchen zu recovern. Ggf. muss man dieses auch mehrmals machen.. also das remounten.. wenn es nach dem booten dann wieder ro ist.


    Ich selber hatte das leider noch nie und konnte es auch nicht nachstellen. Sonst hätte ich das auch mal probiert mit dem rw remounten.


    cya

  • Ist gestern bei mir auch "umgefallen". Einfach so nach einen Reboot aus dem Webif....


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

  • Zitat

    Originally posted by Schnello
    Ist gestern bei mir auch "umgefallen". Einfach so nach einen Reboot aus dem Webif....


    Die Logausschriften, die Du zitierst, sind aber völlig normal. Sieht bei mir bei einem gesunden Boot genau so aus. Wenn das UBIFS geplatzt ist, findet sich das später im Log - entweder den Bootlog richtig aufdrehen oder später auf der Kiste einloggen (wenn das noch geht - kommt drauf an, wie es das FS genau zerlegt hat) und dmesg bzw. /var/log/messages konsultieren.


    HTH,
    Andre.

  • Zitat

    Die Logausschriften, die Du zitierst, sind aber völlig normal.


    Komisch. Die Box wollte einfach nicht mehr weiterstarten (gleich am Anfang wo die Schrift steht bzgl Linux... etc). Hab 5 min gewartet, noch ein paar mal versucht durch Ein und Ausschalten die Box zum starten zu bewegen... hab dann einfach das Image neu geflasht und dann gings wieder...


    Grüße

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


  • Soeben ist mein ubifs auch nur noch readonly gemountet gewesen. Remount und reboot -> läuft, mal sehen wie lange :winking_face:


    kurze Zeit später, beim nächsten Reboot wieder dass Gleiche :frowning_face:
    Ich flash mal schnell neu.

  • BTW, andernthreads schrub ich mal:


    Zitat

    ... der Kernel ist auch immer noch mit

    Code
    UBI: wear-leveling threshold:    4096

    gebaut, obwohl die UBI-Entwickler dringend anraten, das bei NAND-Flash auf 256 zu setzen.


    Die Empfehlung aus der UBI FAQ gilt für MLC Flash, und der Samsung K9F8G08U0M in meiner 7020HD ist trotz dieser irreführenden Ausschrift im Kernel Log

    Code
    nbrBitsPerCell=2, cellinfo=0, chip->cellinfo=00000000

    ein SLC (laut Datenblatt ein 2-Level Cell, und das F in K9F8G08U0M bedeutet auch SLC). Samsung spezifiziert bis zu 100000 nutzbare Erase Cycles (bei Verwendung von ECC, d.h. 1-Bit Corrections gelten nicht als Remapping-Anlass). Damit ist die 4096 statt 256 hier nicht so ungesund wie mir das schien.


    Die selbe Quelle erwähnt übrigens:

    Zitat

    Year 2011 note: however, there is an unsolved unstable bits issue which may make UBI fail to recover after a power cut on modern SLC and MLC flashes. This has never been reported yet for UBI, but has been reported for UBIFS and we believe must be an issue for UBI as well.


    Ich tu mich schwer damit, das sowohl im Trigger (Power Cut zum Flash während Schreib-/Löschoperationen) als auch im Bild (wir sehen praktisch immer "255 but expected 0", das hier sollte zufälliger sein) irgendwie mit unserem Problem zu vereinbaren, aber genaues weiß man erst nach tiefer gehendem Debugging. Interessant wäre mal, ob die ersten Betroffenen diese Probleme schon vor 2013-08 hatten (da kam dieser Patch für brcmnand, oder gar schon vor 2013-06-19, ab da wurde UBIFS sync gemountet weil sich zuvor ja leere Files häuften.


    HTH,
    Andre.


  • Och ne...

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

  • ... ich schließe mich an. :frowning_face:
    remount und es war erst mal wieder ok.

    DM7020HD, DM800HDse


    Dieser Beitrag wurde 2943 mal editiert, zum letzten Mal von Karl Klammer: Heute, 00:15

  • Hi,


    da es ja doch mit gewisser Regelmäßigkeit jemanden erwischt, der das hinkriegen würde - AFAIR kann man im Web-Interface des 2nd stage loaders ja einen Dump des kompletten Flashs für Debuggingzwecke ziehen. Gibt es von Seiten DMM oder der Imageteam-Gurus Interesse an solchen Dumps, damit da mal etwas Forensik am Zustand des UBI(FS) nach "dem Effekt" erfolgen kann? Ich hatte es bisher so verstanden, dass es z.Z. zu schwer reproduzierbar ist - vielleicht hilft es aber schon, wenn jemand mit der nötigen Ahnung (und Zeit) mal parallel so ein dahin geschiedenes UBIFS und den Source Code des Filesystems intensiv genug anstarrt. Ich hatte bei den letzten Updates Glück, aber wer weiß wie lange noch...


    Ich nehme an, wer so'n Dump hat, am besten im IRC vorbeigucken?


    Thanks,
    Andre.

  • Gut zu wissen mit dem Dump. Schaden tut es sicher auch nicht. Zudem mach ich jetzt auch ein 24/7 log... aber ich frage mich ob es nicht besser wäre direkt im DMM Board mal zu posten ob das Problem überhaupt erkannt wurde das es ein Problem gibt...

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

  • Und langsam dacht' ich es wäre Geschichte...


    Gestern Updates machen wollen und vorher das allfällige dflash Backup gestartet. Irgendwie dauerte das länger als erwartet, also mal geguckt: r.ubi war schon 120MB groß. Dabei hat mein / nur 104MB used. Und es wuchs weiter, und weiter, und weiter... Ein Blick ins dmesg zeigte Grüße vom UBIFS:


    Und das ist nur ein winziger Ausschnitt. Aber warum jetzt das runaway dflash? Das da oben sagt es schon durch die Blume (man beachte, dass es immer wieder der selbe Directory Entry ist, der da auftaucht), Klarheit schafft allerdings ein find:


    Na cool, eine Endlosschleife in einem Directory. Mal was Neues, R/O-Filesystem war ja langweilig. Da könnte das mkfs.ubifs noch wochenlang weiter an dem einen File weiterkauen bis die Platte voll ist. Dem Spuk ein Ende bereitet, im SSL den FLASH gesichert und das letzte Backup neu geflasht, danach das Upgrade von MediaPortal (bei dem offenbar das UBIFS diesmal kaputt gegangen ist), alle restlichen Updates nachgezogen und erstmal wieder alles in Butter.


    Was mich jetzt wundert: Ist das Problem anderswo noch so häufig wie vor zwei Monaten oder hat inzwischen jeder ernsthaft Betroffene auf JFFS2 zurückgeflasht? Ich meine auch mal gelesen zu haben, dass ubi0:rootfs inzwischen nicht mehr sync gemountet werden würde. Meins allerdings schon, und das obwohl die Kernel Commandline und /etc/fstab keine Spuren enthalten, die das erklären würden. Frag mich, wie das jetzt wieder geht...


    Andre.

  • Zitat

    und das obwohl die Kernel Commandline und /etc/fstab keine Spuren enthalten, die das erklären würden. Frag mich, wie das jetzt wieder geht...


    Einen alten Eintrag in der /boot/autoexec.bat übersehen?

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

    Einmal editiert, zuletzt von Schnello ()

  • Zitat

    Original von ABPSoft
    Was mich jetzt wundert: Ist das Problem anderswo noch so häufig wie vor zwei Monaten oder hat inzwischen jeder ernsthaft Betroffene auf JFFS2 zurückgeflasht? Ich meine auch mal gelesen zu haben, dass ubi0:rootfs inzwischen nicht mehr sync gemountet werden würde.
    Andre.


    Wann wurde die Änderung mit dem Sync Mount ins Image gebracht?
    Ich kann mich nicht mehr genau an das Datum erinnern, hatte jedoch danach noch mal mit einem neuen Image frisch geflasht und seither keine Probleme mehr, obwohl ich noch auf UBIFS bin.

  • Zitat

    Originally posted by Schnello
    Einen alten Eintrag in der /boot/autoexec.bat übersehen?


    Nope:

    Code
    root@dm7020hd:~# cat /boot/autoexec.bat 
    /boot/bootlogo-dm7020hd.elf.gz filename=/boot/bootlogo-dm7020hd.jpg
    /boot/vmlinux-3.2-dm7020hd.gz ubi.mtd=root root=ubi0:rootfs rootfstype=ubifs rw


    Und vor allem:

    Code
    root@dm7020hd:~# cat /proc/cmdline 
    ubi.mtd=root root=ubi0:rootfs rootfstype=ubifs rw console=ttyS0,115200 debug bmem=192M@64M


    Trotzdem:

    Code
    root@dm7020hd:~# grep ubi /proc/mounts 
    ubi0:rootfs / ubifs rw,sync,relatime 0 0
    /dev/ubi0_1 /data ubifs rw,relatime 0 0


    Ich sag ja, ich steh vor einem Rätsel. Wenn man UBIFS nicht gerade Mountflags in den Superblock brennen kann (so wie bei ext*) dann weiß ich nicht, wo das herkommt (Ok, könnte noch ein hart verdrahteter Hack im Kernel sein, bei OoZooN sind ja ein paar gutemine-Patches mit drin).


    BTW, die Änderung an der Kernel Command Line steckt in diesem Commit. Und wenn die bei DMM gereicht hat, wieso nicht hier...


    Muss mir mal genauer angucken, was dflash da macht, wenn es das r.ubi ubinized. Wenn alles nix hilft kommt ein async in die fstab :winking_face:


    Thanks,
    Andre.

  • Ich weiß gar nicht ob das zu diesem Thema hier passt, aber ich hatte heute Morgen folgendes Problem dass meine DM7020HD nicht aus dem Standby gestartet werden konnte. Ich kam auch nicht mehr mit Telnet auf die Box, so dass mir nichts anderes übrig blieb als den Ein- Ausschalter zu benutzen. Danach startete die Box zwar scheinbar normal (Messageslog stand nichts abnormales drin), allerdings konnte ich die Box danach nicht mehr mit die dFlash sichern.


    Folgende Meldung tauchte im dbackup.log:


    Zitat

    + /tmp/dFlash/bin/mkfs.jffs2 --root=/tmp/boot --disable-compressor=lzo --compression-mode=size --output=/media/hdd/backup/b.img -e 262144 -n -l
    mkfs.jffs2: error!: Usage: mkfs.jffs2 [OPTIONS]
    Make a JFFS2 file system image from an existing directory tree


    Zum Glück hatte ich noch ein relativ neues Image Backup, so dass ich dieses nun flashen konnte. Anschließend habe ich die letzten Updates vom 2. Januar noch mal wieder installiert und es traten (bis jetzt) keine weiteren Probleme mehr auf. Ich hatte jetzt auch schon Monatelang keine Problem mehr, dieser Fehler trat erst nach dem Updates vom 2. Januar auf, aber das kann ja auch nur ein Zufall sein :face_with_rolling_eyes:
    Anbei noch das kpl. dbackup.log