Hallo Jannis,
entschuldige bitte die lange Wartezeit. Ich habe dir die Auswertung eben per E-Mail geschickt, hier im Forum aber auch noch einmal, damit andere etwas davon haben.
Zu deiner Frage mit RevPi 5 und RevPi 4... der erste SOS-Report war einfach von einem anderen Gerät. Dort stand als Produkt ein Connect 4 mit der Seriennummer 157345, im zweiten Report steht der Connect 5 mit der Seriennummer 141980, und die passt zu dem, was Cockpit und Meshcentral bei dir anzeigen. Auch die Uptime von 27 Tagen in deinem Cockpit-Screenshot passt genau zum letzten Neustart in diesem Report. Der Report selbst liest Modell und Seriennummer direkt aus der EEPROM des Geräts, verwechseln kann er sie also nicht. Dass als Hostname host0 auftaucht, kommt nur von der Obfuskierung beim Erstellen des Reports, dabei werden Hostname, IP- und MAC-Adressen ersetzt.
Der zweite SOS-Report ist also vom richtigen Gerät und ich habe es angeschaut.
Ich denke, dass das Update vom 24.04. wurde mitten im Vorgang abgebrochen, dpkg ist seitdem in einem inkonsistenten Zustand und ein apt-get check meldet "dpkg was interrupted". Deshalb konnte danach kein Update mehr installiert werden, auch das über Cockpit nicht. Das Gerät läuft weiterhin mit dem Image 01/2025, Kernel 6.6.0 von November 2024 und piControl 2.3.1, obwohl Cockpit keine offenen Updates mehr anzeigt...
Du kannst folgendes ausprobieren:
Code: Select all
sudo dpkg --configure -a
sudo apt update
sudo apt full-upgrade
sudo reboot
Der erste Befehl läuft auch ohne Internetverbindung. Wichtig ist hier full-upgrade...
Danach kannst du prüfen, ob Kernel 6.12.x und piControl 2.6.x aktiv sind:
Unabhängig davon lief zum Zeitpunkt des Reports codesyscontrol nicht, es lief nur codesysedge.
Prüfe bitte, ob die Runtime läuft und ob die Applikation geladen und im Run-Zustand ist. Ohne laufende Runtime kommen keine Daten an, ganz unabhängig vom Gateway.
Code: Select all
sudo systemctl status codesyscontrol
Ich denke, dass das Gateway gut aussieht. Es wird erkannt, Typ 75 mit Firmware V1.1, und ist mit 480 Byte Ein- und Ausgangsdaten präsent, die PiCtory-Konfiguration passt ebenfalls. Im letzten Bootvorgang, vom 29.05. bis zum Report am 02.06., gibt es keinen einzigen pileft-Fehler mehr. Die Meldungen mit den duplicate data packets und den Timeouts stammen aus dem April und traten immer zusammen mit kurzen Link-Abbrüchen auf der PiBridge auf.
Komisch finde ich, dass eth0 am 02.06. mehrfach den Link verloren hat, dort würde ich mir die Netzwerkseite mit Switch und Verkabelung ansehen.
Gib uns gerne Bescheid, ob das funktioniert hat. Falls danach noch etwas übrig bleibt, schick mir einfach einen neuen SOS-Report.
