Raspi sporadisch teilweise nicht mehr erreichbar

  • Ich vermute auch, dass sich die SSD mit einem I/O Error verabschiedet, oder die root Partition ist schon so korrupt, dass sie sich beim Booten nicht mehr reparieren kann.

    Steck die SSD einmal an der schwarzen USB-2 Buchse an und prüfe das Filesystem (root-Partition) mit "sudo e2fsck -fvn /dev/sda2".

    Lass die SSD länger über USB-2 angesteckt, möglicherweise tritt der "Fehler" dann nicht auf.

    Schau auch in die Ausgabe von "dmesg", ob Du da was unnatürliches findest.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Interessanter Vorschlag - der Speed interessiert in der Tat mich nicht so wirklich, das System war anfangs noch auf einem 3er drauf.

    Funktoniert der fsck auch bei bookworm? Hattte da ebenfalls schon probiert - auch mit den Verfahren /forcefsck zu touchen - getan hat er's aber nie was beim booten. Soweit ich mich erinnere hätte ich dazu die initramfs anfassen müssen - das wollte ich auch erstmal nicht

    Umgestöpselt und nicht überraschenderweise gibt's auch Mecker vom fsck:

  • Funktoniert der fsck auch bei bookworm?

    Wie ist die Ausgabe von:

    Code
    dmesg | grep -i systemd-fsck-root.service

    ?

  • Mit fsck.repair=yes in der config.txt , reboot, update-initramfs und reboot bekomme ich das:

    Code
    [    0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_headphones=0 cgroup_disable=memory numa_policy=interleave snd_bcm2835.enable_headphones=1 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_hdmi=0  smsc95xx.macaddr=E4:5F:01:46:50:81 vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000  console=ttyAMA0,115200 console=tty1 root=PARTUUID=6ccd25d2-02 rootfstype=ext4 fsck.repair=yes rootwait cfg80211.ieee80211_regdom=DE
    [    8.322016] systemd[1]: Created slice system-systemd\x2dfsck.slice - Slice /system/systemd-fsck.
    [    8.435409] systemd[1]: Listening on systemd-fsckd.socket - fsck to fsckd communication Socket.
    [    8.684537] systemd[1]: systemd-fsck-root.service - File System Check on Root Device was skipped because of an unmet condition check (ConditionPathExists=!/run/initramfs/fsck-root).

    Die Datei zu löschen hat leider nix gebracht.
    rpi444 : siehe letzte zeile hier

  • Mit fsck.repair=yes in der config.txt , ...

    Code
    [    0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_headphones=0 cgroup_disable=memory numa_policy=interleave snd_bcm2835.enable_headphones=1 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_hdmi=0  smsc95xx.macaddr=E4:5F:01:46:50:81 vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000  console=ttyAMA0,115200 console=tty1 root=PARTUUID=6ccd25d2-02 rootfstype=ext4 fsck.repair=yes rootwait cfg80211.ieee80211_regdom=DE

    ...

    fsck.repair=yes steht doch per default in der /boot/firmware/cmdline.txt. Siehe die Ausgabe von:

    Code
    cat /boot/firmware/cmdline.txt | grep -i fsck.repair=yes
  • na ja - jetzt steht's ja drin - weil ich's reingeschrieben habe.

    Nein, nicht weil Du es reingeschrieben hast. Das war auch vorher schon drin, weil es in der cmdline.txt drin steht.

    Mich irritiert die "unmet condition" die mir sagt, dass fsck nicht gelaufen ist.

    Ist doch richtig so. Wenn Du weißt was Du tust, kannst Du das ändern, entweder in der service-unit oder die Datei löschen bzw. besser umbenennen.

  • Hmmm...ich habe noch einen anderen Raspi mit dem gleichen Release am laufen - das steht fsck.repair=yes definitv nicht drin - und der ist stock. Und in dem Standard-Image von z.B. Homeassistant isses auch nicht drin? Oder meinst Du was anderes? Ich rede von dem Eintrag fsck.repair=yes in der /boo/firmware/config.txt.


    Wie ich es umbenne, weiß ich leider nicht - nutze normalerweise eher Gentoo ohne systemd - und gelöscht hatte ich die Datei bereits einmal vor nem Reboot, was nichts gebracht hat.


    EDIT : Jetzt weiß ich was Du meinst - lesen bildet machmal eher als man denkt :( Du redest von der cmdline.txt, ich von der config.txt

  • Ich rede von dem Eintrag fsck.repair=yes in der /boo/firmware/config.txt.

    Brauchst Du den (zusätzlichen) Eintrag "fsck.repair=yes" in der /boot/firmware/config.txt, wenn es den Eintrag "fsck.repair=yes" schon in der /boot/firmware/cmdline.txt gibt?

  • ..., wegen der nicht erfülllten Bedingung von der ich nicht weiß, wie ich sie erfüllen kann

    Es wird bei debian schon einen Grund geben, warum der maintainer das so gemacht hat (in der service-unit):

    Code
    ConditionPathExists=!/run/initramfs/fsck-root
    Code
    :~# ls -la /run/initramfs/fsck-root
    -rw-r--r-- 1 root root 0 Jan  1  1970 /run/initramfs/fsck-root

    Wenn Du das warum auch immer ignorieren willst, kannst die service-unit editieren mit systemctl und diese Zeile kommentieren, damit sie nicht mehr wirksam ist:

    Quelle: manpage für systemctl

    EDIT:

    Oder die Datei "/run/initramfs/fsck-root" umbenennen.

  • Nur damit ich das richtig verstehe : dieses Setting ist quasi "fix" im Debian gesetzt? Würde das im Umkehrschluss bedueten, dass kein fsck beim starten nie ausgeführt werden wird, solange diese service-unit diese Daei setzt?
    Dann verstehe ich aber auch nicht, wie ich jemals das root-Dateisystem überprüfen kann - solange es keine Mechanismen gibt, die diesen Eintrag "intern" ausser Kraft setzen

  • Nur damit ich das richtig verstehe : dieses Setting ist quasi "fix" im Debian gesetzt? Würde das im Umkehrschluss bedueten, dass kein fsck beim starten nie ausgeführt werden wird, solange diese service-unit diese Daei setzt?
    Dann verstehe ich aber auch nicht, wie ich jemals das root-Dateisystem überprüfen kann - solange es keine Mechanismen gibt, die diesen Eintrag "intern" ausser Kraft setzen

    Ich verstehe das so: Wann bzw. ob fsck (filesystemcheck) gemacht wird, weiß das system u. a. auch von der Anzahl der boot-Vorgänge. Diese service-unit ist "enabled-runtime" (d. h. zur Laufzeit bzw. beim booten) und diese Bedingung (d. h. das erstellen der leeren datei) /run/initramfs/fsck-root erfolgt auch beim booten. Wenn das system beim booten erkennt, dass ein fsck fällig bzw. erforderlich ist, wird es die leere Datei "/run/initramfs/fsck-root" _nicht_ erstellen und somit wird der fsck beim booten stattfinden. Wie das System dann den Datenträger einhängt weiß ich nicht und deshalb würde ich das auch nicht manuell ausführen. Außer ich entnehme den Datenträger und teste ihn unmounted (nicht eingehängt) auf einem anderen System.

    EDIT:

    BTW: Wann der letzte check statt gefunden hat, kann man auch im eingehängten Zustand sehen. Z. B.:

    Code
    :~# tune2fs -l /dev/mmcblk0p2 | grep -i 'last checked'
    Last checked:             Tue Nov 19 14:38:55 2024

    EDIT 2:

    Quote

    Diese Prüfprogramme entscheiden basierend auf der Zeit seit der letzten Überprüfung, der Anzahl der Einhängungen, unsauberen Aushängungen usw., ob das Dateisystem tatsächlich geprüft werden soll.

    Quelle: man systemd-fsck

    Wi-Fi_Signal_Strength  txpower
    iptables chains order scheme iptables-diagram
    nftables-diagram

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.6 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p10 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., Mumble-Serv., ddclient

    PI4B/8GB Bookworm-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server, botamusique, ample

    Edited 2 times, last by rpi444 (January 27, 2025 at 5:52 PM).

  • Ist gerade nochmal passiert - wie üblich.
    Kein shellinabox, kein ssh, keine Logs.
    Ich gehe davon aus, dass sich die SSD verabschiedet - hab jetzt einen anderen Controller mit einer anderern, kleineren SSD genommen, frisch installiert und die Daten aus 'nem Backup wiederhergestellt.
    Hoffe, es hat sich damit erledigt....

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!