Enigma2 startet plötzlich nicht mehr (Fehler in lamedb)

    Hallo,


    seit heute morgen will meine DM7020 HD (OE2 experimental) nicht mehr richtig starten. Das Booten funktioniert noch (glücklicherweise), aber beim Starten von enigma2 hängt die Box. Die Debug-Ausgabe zeigt abschließend folgenden Fehler:


    Code
    ---- opening lame channel db
reading services (version 4)
Bus error


    Ich habe dann versucht, die lamedb über cat /etc/enigma2/lamedb zu lesen, doch nach einigen Zeilen brach die Ausgabe mit folgender Meldung ab:


    Code
    Neocat: read error: Input/output error


    Ich habe gestern nichts Besonderes gemacht, insbesondere auch kein Update durchgeführt oder Software installiert. Könnt ihr mir helfen, die Kiste wieder zum Laufen zu bringen? :smiling_face:


    ph4nt0m

    Sind im dmesg und/oder in /var/log/messages ubifs Fehler während des I/O Errors zu sehen?
    Falls ja, dann ist wahrscheinlich Dein Flashdateisystem hinüber und Du musst neu flashen. Dabei wäre es dann interessant zu wissen, wann Du dein aktuelles Image geflasht hattest.

    Ich habe deine Antwort leider zu spät gelesen und inzwischen die lamedb umbenannt. Danach ist die Box wieder komplett hochgefahren, nur ein neuer Sendersuchlauf war natürlich erforderlich, um eine neue lamedb zu erzeugen. Bislang klappt alles so wie vorher. :smiling_face:


    Wenn ich die alte, fehlerhafte lamedb jetzt mit cat ausgeben möchte, werden folgende Zeilen zu dmesg hinzugefügt:


    Code
    [  456.121000] UBIFS error (pid 1450): ubifs_read_node: bad node type (255 but expected 1)
[  456.122000] UBIFS error (pid 1450): ubifs_read_node: bad node at LEB 1315:0, LEB mapping status 1
[  456.124000] UBIFS error (pid 1450): do_readpage: cannot read page 2 of inode 8543, error -22
[  456.128000] UBIFS error (pid 1450): ubifs_read_node: bad node type (255 but expected 1)
[  456.129000] UBIFS error (pid 1450): ubifs_read_node: bad node at LEB 1315:0, LEB mapping status 1
[  456.130000] UBIFS error (pid 1450): do_readpage: cannot read page 2 of inode 8543, error -22


    Im Anhang findet ihr die Zeilen aus var/log/messages, die das Dateisystem betreffen. Es sieht tatsächlich so aus, als wenn einiges fehlerhaft ist. Aber wie kritisch sind diese Ausgaben? Wenige defekte Blöcke scheinen beim Flash-Speicher ja nicht ungewöhnlich zu sein und bisher läuft die Box wieder genau wie vorher.

    Das Problem mit diesen Fehlern ist, dass sie mit der Zeit oft mehr werden, bis irgendwann gar nichts mehr geht.
    Deswegen lieber - solange es noch unproblematisch möglich ist - backuppen und neu flashen.


    Wann hast Du das Image ursprünglich geflasht?

    OK, kann ich denn den aktuellen Stand komplett sichern und dann nach dem Flashen wiederherstellen? Ich würde ungern wieder alles neu einstellen bzw. jede wichtige Datei einzeln sichern. Geflasht habe ich irgendwann Mitte August.

    Komplett sichern im Sinne von dFlash Backup? Nein.
    Du kannst aber versuchen die einzelnen Config Dateien mitzunehmen. Treten dabei keine I/O Errors auf, sollte es keine Probleme geben.


    Der Hintergrund zu der Datumsfrage: Ghost hat in den UBIFS Mountoptionen den Sync herausgenommen. Das war soweit ich mich erinnere Ende September.
    Seitdem sind bei "Neuflashern" afaik keine UBIFS Probleme mehr aufgetreten.
    Hatte das Dateisystem aber von den alten Mountoptionen schon einen Schuss weg, dann hat auch das nachträgliche Ändern der Mountflags per Online Update nichts mehr geholfen und den eventuellen Dateisystemtod nur herausgezögert.

    Alles klar, danke für deine Hilfe. Dann werde ich mich mal ans "backuppen" machen und spätestens morgen neu flashen.


    Gibt es irgendeine Möglichkeit, nach dem Flashen festzustellen, ob das Dateisystem vollständig fehlerfrei und konsistent ist? Falls ja, so würde ich gerne ein Komplettbackup machen. Ich nehme an, dazu ist dFlash am besten geeignet, oder? :smiling_face:

    Im Rahmen eines Backups werden alle File des Filesystems gelesen, und in der aktuellen Version vom dFlash auch gecheched ob dabei wieder IO Fehler auftreten.


    Viel mehr kann man allerdings nicht machen das Flasfilesystem typischerweise keinen Filesystemcheck kennen.


    Und das wegnehmen der sync Option beim ubifs hat nur dazu geführt dass das ubifs recovery wieder frei atmen konnte. Fehler können da immer noch auftreten, aber wenn das recovery ordnungsgemäß arbeitet sollten sie auch beim booten/mounten wieder recovered werden und das Filesystem intakt bleiben.