Raspi Beendet oberfläche sporadisch

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Moin,

    ich habe seit geraumer Zeit ein Problem mit meinem RaspberryPi 4 und zwar Läuft auf ihm IoBroker, InfluxDB, Grafana, Pihole und Deconz. Das lief auch alles Ohne Probleme bis ich eine Festplatte angeschlossen hab.

    Nun hab ich das Problem das die Grafische ober Fläche des Pi sich beendet und er in der Console wechselt. Wodurch Deconz und noch ein paar Programme nicht mehr weiter laufen.

    Dachte am Anfang das es evtl. eine Spannungsproblem ist da es wenn er über sd karte läuft nicht vorkommt, leider brachte das Netzteil für die Festplatte keinen Abhilfe des Problems, und in den Log Dateien kann ich auch nichts finden.

    Sobald ich InfluxDB nichtmehr Starte ist das Problem nicht mehr vorhanden.

    Hat jemand eine Idee was ich noch probieren kann??

    :danke_ATDE:

  • Das klingt wirklich voellig absurd. InfuxDB sollte da eigentlich ueberhaupt keinen Einfluss haben. Ausser das es Speicher verbraucht. Das waere das einzige, das ich mir erklaeren kann: der Hauptspeicher geht aus, und ggf. ist durch den Festplattenumbau die swap-Partition/Datei deaktiviert/verschwunden. Und dann kracht die grafische Oberflaeche weg, wenn InfluxDB den Speicher aufgehamstert hat.

    Probier doch mal dieses Programm zu starten, wenn die grafische Oberflaeche laeuft:

    Python
    #!/usr/bin/env python3
    from itertools import count
    big_list = []
    
    for i in count():
        big_list.append(i)

    Das allokiert einfach langsam aber sicher endlos Speicher. Und wenn deine UI wegbricht, dann waere das ein guter Hinweis, dass meine These stimmt.

  • Na dann ist das Problem doch ziemlich klar ---- Festplatte!

    Welches Netzteil verwendest Du?

    Wie ist die Festplatte angeschlossen ? Wie das Netzteil der Platte?

    Netzteil vom Rasbpi war das was dabei ist das hat 3 A

    und das was ich dann dannach für die Platte geholt hab hat 2 A

  • Das klingt wirklich voellig absurd. InfuxDB sollte da eigentlich ueberhaupt keinen Einfluss haben. Ausser das es Speicher verbraucht. Das waere das einzige, das ich mir erklaeren kann: der Hauptspeicher geht aus, und ggf. ist durch den Festplattenumbau die swap-Partition/Datei deaktiviert/verschwunden. Und dann kracht die grafische Oberflaeche weg, wenn InfluxDB den Speicher aufgehamstert hat.

    Probier doch mal dieses Programm zu starten, wenn die grafische Oberflaeche laeuft:

    Python
    #!/usr/bin/env python3
    from itertools import count
    big_list = []
    
    for i in count():
        big_list.append(i)

    Das allokiert einfach langsam aber sicher endlos Speicher. Und wenn deine UI wegbricht, dann waere das ein guter Hinweis, dass meine These stimmt.

    hat er gemacht.

    Oberfläche ist nicht abgeschmiert

    hat ca. 3650 mb von 3906mb vollgemacht da hatte python ca 2,6 gb in nutzung und hat dann memory error rausgeworfen.

  • In welchen hast Du denn nachgesehen ?

    Klingt so, alsob der X-Server beendet wird, bzw. abstürzt. Das sollte im Xorg, oder kern - Logfiles schon sichtbar sein.

    <startx> reagiert auch nicht mehr ?


    Servus !

    in der kern.log steht nicht wirklich was am 15.06 ist er um 3:30 uhr und um 12:04 uhr aus der oberfläche gegangen und in der log ist der letzt eintrag 3:17 uhr und 11:55 uhr

    und in der xorg.log steig ich nicht durch :D

  • rar? Wieso ist das noch ein Ding? Pack das doch unkomprimiert oder zur Not mit ZIP hierhin, aber ein 90er Jahre Movie ripper format kann ich hier auf dem iPad nicht entschlüsseln.

  • Es ist etwas seltsam, dass du da tausende male die Modelines drinstehen hast. Statt dem Kernel-Log, das nur die Bootphase beschreibt, bitte mal das relevantere syslog schicken.

    Wenn da auch nix drin steht, holen wir die schweren Geschuetze raus...

  • 15 11:55:41 raspberrypi kernel: [ 0.000000] Kernel command line: coherent_pool=1M ....... root=PARTUUID=174f8cfa-02 rootfstype=ext4 .........

    Jun 15 11:55:41 raspberrypi kernel: [ 0.497497] Waiting for root device PARTUUID=174f8cfa-02...

    Jun 15 11:55:41 raspberrypi kernel: [ 0.556795] mmcblk0: p1 p2

    Jun 15 11:55:41 raspberrypi kernel: [ 1.688231] sda: sda1 sda2

    Jun 15 11:55:41 raspberrypi kernel: [ 1.743372] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)

    Jun 15 11:55:56 raspberrypi kernel: [ 23.695494] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

    Jun 15 11:55:56 raspberrypi kernel: [ 23.952921] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)

    --Absturz/Reboot

    Also, im kernlog sehe ich immer die gleichen Fehler: Der Pi bootet von /dev/mmblk0 p1 und zeigt auf die root-Partition: PARTUID=17...fa-02. Im early-boot wird ein fschk von /boot und/root ausgeführt, wie in /etc/fstab des EXT4 Filesystems mit der PARTUID=17...fa-02 einetragen, und mit derselben Eintragung wird abschliessend auch die /boot- und rootpartition rw gemountet. Das ist aber /dev/sda1 für /boot und /dev/mmblk0-p2 füt /root. Die verdrehte Konfiguration geht solange gut, bis durch ein Update die BS-Versionen auseinandergehen, weil ein Update auf /dev/sda1 (Boot- und Kernelfiles) und /dev/mmblk-p2 (Rest-Linux) durchführt. Wenn verschiedene Versionen von Kernel und Libs, oder anderen ELF-Binaries zusammentreffen kann dies zu einem blitzartigen Kernel Panic kommen, für dessen Protokollierung keine Zeit mehr bleibt.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Heißt ? Ist mein Boot pfand falsch oder wie ?? hatte den umzug von sd auf sata damals mit usb-boot tool gemacht.

    im anhang die syslog von dem tag

  • Keine Ahnung, was Du mit usb-boot tool damals angestellt hast. Ich kenne das Frontend nicht.

    Und 187.645 Zeilen des Logfiles lese ich mir Zeile für Zeile sicher nicht durch, um Dir sagen zu können, was Du damals falsch gemacht hast.

    Du kannst aber selbst die Ausgabe von zcat /var/log/syslog.7.gz nach Error, oder E! mit grep Filtern, solange .7.gz noch nicht wegrotiert wird.

    < zcat /var/log/syslog.7.gz | grep Error >. Was Du damit dann machst, bleibt Dir überlassen.

    Wenn mein Verdacht richtig ist, dass Du ein Update auf mmc-p2 und sda1 durchgeführt hast, kannst Du versuchen mit der boot-Partition von mmc-p1 und der root-Partition von mmc-p2 zu starten und danach die Partitio/Daten von sda1 auf mmc-p1 zu übertragen. Das setzt aber vorraus, dass das Datum der geänderten Daten in sda1 jünger ist, als auf mmc-p1 und derjenigen von mmc-p2 jümger, als sda2.

    Datensicherung vor weiteren root-Zugriffen ist jedenfalls erfolderlich.

    Servus !

    RTFM = Read The Factory Manual, oder so

  • Mit grep bekommt man das syslog recht gut runter gefiltert - aber tatsaechlich sind iobroker und influxd *sehr* geschwaetzig, da kannst du mal dran drehen. Soviel bracht man da nicht.

    Doch wenn man das runterbricht, erschliesst sich auch erstmal nichts offensichtliches. Auch wenn du ja so ziemlich alles da laufen hast, was man so laufen lassen kann.

    Du kannst mal probieren core-dumps zu enablen, und dann sehen wir, ob der x-prozess kracht.

  • Hmm ok, dann muss ich mich da mal durch fuxen, hab die datei ja auf dem pc um die zu durchforsten.

    mmc-p1 bzw 2 sind die partitionen sehe ich das richtig ? letztes mal ging auch nach dem update nix mehr hatte dann die platte auf die sd geschoben dann alle updates gemacht und dann wieder usb-boot drüber laufen lassen. aber was da schief gelaufen ist keine ahnung.

  • wenn ich das jetzt richtig verstehe hat er also beim kopieren, ein paar rechte nicht richtig übertragen weshalb er sich jetzt vertüddelt und dadurch evtl abschmiert ? bzw man es deshalb nicht mehr richtig nach volziehen kann ?

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!