Filesystem kaputt? Kein reboot mehr.

  • Das Problem ist wahrscheinlich auch nicht der NFS-Server

    Denke ich auch nicht.

    Die Ursache wird wohl das defekte Filesystem sein.

    Ich glaube nicht dass es am trim liegt. Ueblicherweise liegt sowas an der Stromversorung. Die WD schreibst Du ist extern mit Strom versorgt. Ich wuerde mal die SSD auch extern versorgen.

    "Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect." Linus Benedict Torvalds, 28.9.2003


    Hast Du die Woche schon Deine Raspberry gesichert :shy: Bei mir tut das automatisch raspiBackup ;)

  • Also Backup geflasht und neugestartet. Danach ging es.

    Und wenn das Backup schon einen Fehler (im Filesystem) hat, kommst Du damit immer gleich weit. Z.B. bis zum ersten, oder zweiten Steckerziehen.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Und wenn das Backup schon einen Fehler (im Filesystem) hat, kommst Du damit immer gleich weit. Z.B. bis zum ersten, oder zweiten Steckerziehen.


    Servus !

    Ja, das stimmt. Das hoffe ich jetzt mal einfach nicht. Ansonsten müsste ich 2-3 Backups zurück gehen oder alles neu machen.

    Ich tippe auf den trim, da der Adapter den Trim-Befehl nicht von Anfang an unterstützt hat. Ich hab das dann mit einer udev-Regel hinbekommen, natürlich nur abgeschrieben, da ich da nicht so viel Ahnung von habe.

    Code
    /etc/udev/rules.d/50-usb-ssd-trim.rules
    
    ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="55aa", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"

    Wie gesagt, ich schau mal in wie weit bzw. wie lange das ohne trim funktioniert.

  • Ja, das stimmt. Das hoffe ich jetzt mal einfach nicht. Ansonsten müsste ich 2-3 Backups zurück gehen oder alles neu machen.

    Dass trimm für den unreparablen Absturz verantwortlich ist, kann ich mir nicht vorstellen.


    Wenn Du die letzte Datensicherung zurückflasht und dann sofort ein check & repair durchführst, hast Du die aktuellsten Daten wiederhergestellt. Und auch auf ein "sync" vor dem Abstecken der SSD nicht vergessen.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Moin.

    Gestern war es wieder so weit. Der NFS-Mount ist nicht gefunden worden und ein reboot funktionierte nicht mehr. Ziemlich genau nach 2 Wochen.

    Im Syslog ist folgendes zu finden:

    Und das wiederholt sich dann noch 2-3 mal.

    Im Anhang nochmal der Syslog von gestern.

    Ich bin dabei raus. Sieht irgendwie nach speicherproblem aus. Kann sein, dass sich die SSD verabschiedet?

    Die ist zwar noch nicht so alt, ist aber eine günstige gewesen...

  • root@SmarthomeNG:~# sudo e2fsck -nfv /dev/sda1

    e2fsck 1.44.5 (15-Dec-2018)

    Warning! /dev/sda1 is mounted.

    ext2fs_open2: Bad magic number in super-block

    e2fsck: Superblock invalid, trying backup blocks...

    e2fsck: Bad magic number in super-block while trying to open /dev/sda1


    The superblock could not be read or does not describe a valid ext2/ext3/ext4

    filesystem. If the device is valid and it really contains an ext2/ext3/ext4

    filesystem (and not swap or ufs or something else), then the superblock

    is corrupt, and you might try running e2fsck with an alternate superblock:

    e2fsck -b 8193 <device>

    or

    e2fsck -b 32768 <device>


    /dev/sda1 contains a vfat file system labelled 'boot'


    Sieht nicht so gut aus...

  • Sieht trotzdem nicht gut aus...

  • Dann werde ich mal beim nächsten mal die Syslogs durchforsten.

    #10 Hast Du nicht gemacht, sonst hättest Du bei jedem Booten den Hinweis gesehen, dass Du das Root-Filesystem manuell reparieren sollst. Das geht nur am un-gemounteten Device, d.h. Du musst die SSD an einem anderen Linux anstecken. (z.B. an einen mit einer SD gestarteten Pi).


    Wie soll NFS fehlerfrei funktionieren, wenn das darunterliegende Filesystem korrupt ist ?



    Servus !

    RTFM = Read The Factory Manual, oder so

  • Es gab seit dem letzten mal (vor 2 Wochen) keinen Neustart.

    Das Ding läuft im Server-Betrieb 24/7 ohne Monitor und Oberfläche.

    Beim letzten mal habe ich die SSD an ein Ubuntu-Rechner gesteckt und mit Gparted die Partition ausgesucht und reparieren lassen. Danach ging auch nix mehr.

    Jetzt werde ich das nochmal mit einem Ubuntu-Rechner machen und nochmal probieren.

    Wie geht so ein Filesystem denn kaputt?

    In allen Log (1-7) hab ich auch nichts von Undervolt oder dergleichen gefunden.

    Außer im letzten Log, den ich gepostet hab, war nach dem rausziehen des Steckers und folgendem Neustart ein Eintrag zu finden. Als

    Kernel command Line mit fsck.repair=yes.

    Ansonten ist nix zu finden.

  • Wie geht so ein Filesystem denn kaputt?

    Wenn der Inhalt der Zwischenspeicher noch nicht ins Filesystem (samt Journal) rausgeschrieben wurde.

    Das passiert beispielsweise durch vorzeitige Unterbrechung der Stromzufuhr, durch Abziehen des (ungemounteten) USB Gerätes ohne vorherigem < sync >, oder durch Abziehen des (gemounteten) USB Gerätes ohne "Auswerfen/Sicher entfernen"


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Tja, und nun?

    Absichtlich war nix von alledem.

    In den Logs ist nichts von Undervolt etc. zu finden.

    Also SSD oder Sata-USB-Adpater, wobei doch dann noch mehr nicht mehr funktionieren müsste, oder?

    Und immer der NFS-Server?


    Ich werde die SSD mal reparieren lassen und beim nächsten mal gegen eine andere Austauschen. Vielleicht hau ich erstmal ne Micro-SD-Karte rein und lass es damit laufen. Dann kann ich mich mal um die SSD kümmern...

  • Nachdem letzte Woche dann die SD-Karte auch ne Macke hatte, lustigerweise hat der NFS-Server und die Hausautomatisierung noch funktioniert, dafür aber der SSH Zugang nicht mehr..., habe ich nun wieder ne SSD dran. Gestern hatte ich den DryRun gemacht und gesehen, dass wieder einige Inodes nicht ok sind. Heute dann mal ein reboot gemacht und im log nachgesehen und gesehen, dass der fsck ausgeführt worden ist.

    Beim DryRun im gemounteten System macht er noch Block Count fehler.

    Vielleicht lass ich den Pi 1 x wöchentlich einfach ein reboot machen und schau dann mal wie es weiter läuft...