NEWS
MQTT Adapter does not start any more after raspi-crash
-
uiuiui, ja wenn möglich, ich gelobe Besserung und entschuldige mich.
Meine nächste oder letzte Frage hier wäre nämlich... lässt sich so ein Fehler beheben, kann man einfach die Platte reparieren, oder nehme ich lieber das Backup was ich kurz vorher gemacht habe (das war nämlich der Grund für die SSD am alten Raspi)...
-
S Samson71 verschob dieses Thema von ioBroker general am
-
uiuiui, ja wenn möglich, ich gelobe Besserung und entschuldige mich.
Meine nächste oder letzte Frage hier wäre nämlich... lässt sich so ein Fehler beheben, kann man einfach die Platte reparieren, oder nehme ich lieber das Backup was ich kurz vorher gemacht habe (das war nämlich der Grund für die SSD am alten Raspi)...
@NoPlayBack-0
Ist wieder im Deutschen Bereich, allerdings bei "Pflege des Betriebssystems". Du hast nen Schuss im Dateisystem. @homoran hat Dir das im Beitrag #4 aufgezeigt. Ich würde wohl zum Backup greifen denke ich, sofern das vor den Problemen entstanden ist. -
Sodelle.... raspiBackup zurückgespielt, Fehler immer noch da.
In iob diag ist immer noch die Zeile zu sehen:
[Sat Jan 3 16:46:16 2026] EXT4-fs (nvme0n1p2): orphan cleanup on readonly fsAlso war der Fehler wohl schon beim Backup vorhanden, muss aber sehr sehr kurz vorher entstanden sein weil der MQTT-Adapter bis wenige Minuten vorher noch Daten empfangen hat und die in der db gespeichert wurden.
Das einzige was ich vorher gemacht hatte in dem Zeitraum (wegen dem anderen Problem hier: https://forum.iobroker.net/topic/83446/meldung-auth-could-not-identify-password-for-iobroker) war der Versuch, iob diag laufen zu lassen was wegen Rechteprobleme nicht ging. Ich hatte versucht den User pi zur Gruppe iobroker hinzuzufügen mit "sudo usermod -a -G iobroker pi" was aber auch nicht geholfen hatte.
Dann hatte ich vorsichtshalber ein Backup gemacht und danach erst mit iob fix das Rechteproblem gelöst. Obwohl dort keine Abfrage nach einem User und Passwort kam konnte ich nacher als pi den Befehl iob diag laufen lassen.Wieso läuft alles, nur dieser MQTT bleibt auf gelb hängen ?????
-
Ich hätte hier noch ein Backup aus dem gleichen Moment... ich mache auch immer ein Image mit SDCard-Kopier.... aber das kann ja nichts anderes machen?
Oder wäre das ein Versuch wert ??? -
Sodelle.... raspiBackup zurückgespielt, Fehler immer noch da.
In iob diag ist immer noch die Zeile zu sehen:
[Sat Jan 3 16:46:16 2026] EXT4-fs (nvme0n1p2): orphan cleanup on readonly fsAlso war der Fehler wohl schon beim Backup vorhanden, muss aber sehr sehr kurz vorher entstanden sein weil der MQTT-Adapter bis wenige Minuten vorher noch Daten empfangen hat und die in der db gespeichert wurden.
Das einzige was ich vorher gemacht hatte in dem Zeitraum (wegen dem anderen Problem hier: https://forum.iobroker.net/topic/83446/meldung-auth-could-not-identify-password-for-iobroker) war der Versuch, iob diag laufen zu lassen was wegen Rechteprobleme nicht ging. Ich hatte versucht den User pi zur Gruppe iobroker hinzuzufügen mit "sudo usermod -a -G iobroker pi" was aber auch nicht geholfen hatte.
Dann hatte ich vorsichtshalber ein Backup gemacht und danach erst mit iob fix das Rechteproblem gelöst. Obwohl dort keine Abfrage nach einem User und Passwort kam konnte ich nacher als pi den Befehl iob diag laufen lassen.Wieso läuft alles, nur dieser MQTT bleibt auf gelb hängen ?????
@NoPlayBack-0 sagte in MQTT Adapter does not start any more after raspi-crash:
war der Versuch, iob diag laufen zu lassen was wegen Rechteprobleme nicht ging. Ich hatte versucht den User pi zur Gruppe iobroker hinzuzufügen mit "sudo usermod -a -G iobroker pi" was aber auch nicht geholfen hatte.
Bei einem 'ordentlichen Setup' (bei dem der user pi (bzw. ein anderer Standarduser) verwendet wird) ist der user immer auch in der Gruppe 'iobroker' enthalten.
danach erst mit iob fix das Rechteproblem gelöst. Obwohl dort keine Abfrage nach einem User und Passwort kam konnte ich nacher als pi den Befehl iob diag laufen lassen.
Der 'iob fix' löst kein Rechte-'Problem', weil es da nie 'Probleme' gibt, lediglich nicht korrekt gesetzte Rechte. Der Fixer greift dem Admin des Systems nur etwas unter die Arme und richtet die Rechte für ihn ein.
-
Sodelle.... raspiBackup zurückgespielt, Fehler immer noch da.
In iob diag ist immer noch die Zeile zu sehen:
[Sat Jan 3 16:46:16 2026] EXT4-fs (nvme0n1p2): orphan cleanup on readonly fsAlso war der Fehler wohl schon beim Backup vorhanden, muss aber sehr sehr kurz vorher entstanden sein weil der MQTT-Adapter bis wenige Minuten vorher noch Daten empfangen hat und die in der db gespeichert wurden.
Das einzige was ich vorher gemacht hatte in dem Zeitraum (wegen dem anderen Problem hier: https://forum.iobroker.net/topic/83446/meldung-auth-could-not-identify-password-for-iobroker) war der Versuch, iob diag laufen zu lassen was wegen Rechteprobleme nicht ging. Ich hatte versucht den User pi zur Gruppe iobroker hinzuzufügen mit "sudo usermod -a -G iobroker pi" was aber auch nicht geholfen hatte.
Dann hatte ich vorsichtshalber ein Backup gemacht und danach erst mit iob fix das Rechteproblem gelöst. Obwohl dort keine Abfrage nach einem User und Passwort kam konnte ich nacher als pi den Befehl iob diag laufen lassen.Wieso läuft alles, nur dieser MQTT bleibt auf gelb hängen ?????
@NoPlayBack-0 sagte in MQTT Adapter does not start any more after raspi-crash:
Also war der Fehler wohl schon beim Backup vorhanden
nöö, die Platte scheint massive Probleme zu haben, und/oder die Einschläge sind in Dateien vom OS, node.js...ä
-
so und jetzt wird es richtig komisch... habe gerade nachgeguckt, der MQTT-Adapter auf dem alten Raspi (den hatte ich deaktivert) zeigt jetzt das gleiche Verhalten, wird nicht grün.
Der MQTT-Adapter auf einem dritten Raspi ebenfalls, bleibt auf gelb.
Ich bin ratlos ... -
Sodelle.... raspiBackup zurückgespielt, Fehler immer noch da.
In iob diag ist immer noch die Zeile zu sehen:
[Sat Jan 3 16:46:16 2026] EXT4-fs (nvme0n1p2): orphan cleanup on readonly fsAlso war der Fehler wohl schon beim Backup vorhanden, muss aber sehr sehr kurz vorher entstanden sein weil der MQTT-Adapter bis wenige Minuten vorher noch Daten empfangen hat und die in der db gespeichert wurden.
Das einzige was ich vorher gemacht hatte in dem Zeitraum (wegen dem anderen Problem hier: https://forum.iobroker.net/topic/83446/meldung-auth-could-not-identify-password-for-iobroker) war der Versuch, iob diag laufen zu lassen was wegen Rechteprobleme nicht ging. Ich hatte versucht den User pi zur Gruppe iobroker hinzuzufügen mit "sudo usermod -a -G iobroker pi" was aber auch nicht geholfen hatte.
Dann hatte ich vorsichtshalber ein Backup gemacht und danach erst mit iob fix das Rechteproblem gelöst. Obwohl dort keine Abfrage nach einem User und Passwort kam konnte ich nacher als pi den Befehl iob diag laufen lassen.Wieso läuft alles, nur dieser MQTT bleibt auf gelb hängen ?????
@NoPlayBack-0 sagte in MQTT Adapter does not start any more after raspi-crash:
In iob diag ist immer noch die Zeile zu sehen:
[Sat Jan 3 16:46:16 2026] EXT4-fs (nvme0n1p2): orphan cleanup on readonly fsWas heißt immer noch? Das ist ein neuer Eintrag. Es wurden also bei diesem Boot weitere/neue verwaiste Einträge gelöscht.
Spricht für einen wurmstichigen Datenträger, wenn der Neustart ordentlich durchgeführt wurde jedenfalls. -
Link zum gleichlautenden Issue: https://github.com/ioBroker/ioBroker.mqtt/issues/582
-
so und jetzt wird es richtig komisch... habe gerade nachgeguckt, der MQTT-Adapter auf dem alten Raspi (den hatte ich deaktivert) zeigt jetzt das gleiche Verhalten, wird nicht grün.
Der MQTT-Adapter auf einem dritten Raspi ebenfalls, bleibt auf gelb.
Ich bin ratlos ...Betriebst du den mqtt Adapter als client oder als server?
Wenn der Adapter als Server / Broker läuft:
Hast du ggF die IP Addressen bei den clients angepasst? Ein neuer Rechner hat ja mit einer gewissen Wahrscheinlichkeit eine neue IP. Ohne Anpassen der clients werden die den nicht finden. -
Jupp... habe ich, bzw. die nutzen keine IP sondern DNS, aber ja, die IPs habe ich tatsächlich bei den Raspis manuell und fix vergeben. Der Adapter läuft als Server/Broker.
Und... die liefen nach der ganzen Umstellung ja auch bis gestern abend.... -
Neee nä ?
Meine Gedanken gingen in die gleiche Richtung daher war ich gerade dabei und habe einen Client umprogrammiert auf die fixe Adresse.... und zack, der Adapter wird grün.
In meiner FritzBox gibt es gerade im Netzwerk 2 Geräte mit unterschiedlichen IPs, aber sie haben den gleichen Netzwerknamen !?!?!?!?!?
Nachtrag: Eins ist das WLAN das andere kabelgebunden.....
Nachtrag2: .... und damit zu früh gefreut... WLAN abgeschaltet (wie ich es bei den anderen Raspis auch hatte), wieder versucht den Server/Broker mit Netzwerknamen anzusprechen, es kommt kein Connect, die Clients können sich nicht verbinden...
Morgen ist auch noch ein Tag. -
so, neuer Tag neues Glück:
Erst einmal vielen Dank an die super Unterstützung hier, ich weiß jetzt wo die Ursache ist, beheben konnte ich sie noch nicht.
Ich hatte beim Umbau von alt auf neu ein paar mal IPs und Namen der Netzwerkgeräte gewechselt, mit dem Ziel, dem Haupt-Raspi die gleiche IP und den gleichen Namen zu geben wie vorher.
In der Fritzbox ist nun bei den Geräteinformationen zwar der richtige Name eingetragen, aber es gibt dort auch einen Eintrag "Erstverbindung ins Heimnetz als:" und dort steht der Name-02 drinne... ich vermute das ist der Name den ich beim ersten Start von Trixie vergeben hatte.
Wenn ich heute mit tracert IP in einem Windows-Terminal nachschaue dann kommt dort die Rückmeldung, dass unter der IP das Gerät Name-02 ist.
Wenn ich tracert Name teste kommt das gleiche Ergebnis, mit tracert Name-02 gibt es "Name konnte nicht aufgelöst werden".
Ein ping klappt mit beiden Namen.
Wenn ich einen MQTT-Client programmiere mit dem Namen, kann keine Verbindung aufgebaut werden.
Wenn ich einen MQTT-Client programmiere mit dem Namen-02, dann wird eine Verbindung aufgebaut.
Mit IP natürlich auch.Ich vermute dass beim crash gar nix passiert ist... außer dass der neue raspi halt neu gestartet werden musste und er ab dem Zeitpunkt dann mit dieser Situation nicht mehr klarkommt... bzw. der Adapter.
Langer Rede kurzer Sinn: Ich würde mich freuen Hilfe zu bekommen die Ursache zu finden und auch zu beheben, aber das ist ja jetzt eigentlich ein anderes Thema. Ich möchte nicht einfach nur in den Clients jetzt die IPs eintragen, ich würde gerne beim Namen bleiben, daher muss ich mal herausfinden wie ich das löse.
Eine viel wichtigere Frage die hier vielleicht noch hinpasst:
Ihr habt mir ja jetzt gezeigt dass meine Platte offensichtlich Kummer hat. Wo kann ich da mehr lesen bzgl. SSD-Test, SSD-Health, Ursachen-Analyse?
An der Stelle noch ein kleiner Hinweis: Ich habe in der config.txt das pciex1_gen=3 gesetzt um die Geschwindigkeit höher zu zwingen... in einem anderen Forum wurde mir gesagt dass das alle machen und bis jetzt noch keine Schwierigkeiten bekannt sind...oder gibt es hier eine andere Meinung ? -
so, neuer Tag neues Glück:
Erst einmal vielen Dank an die super Unterstützung hier, ich weiß jetzt wo die Ursache ist, beheben konnte ich sie noch nicht.
Ich hatte beim Umbau von alt auf neu ein paar mal IPs und Namen der Netzwerkgeräte gewechselt, mit dem Ziel, dem Haupt-Raspi die gleiche IP und den gleichen Namen zu geben wie vorher.
In der Fritzbox ist nun bei den Geräteinformationen zwar der richtige Name eingetragen, aber es gibt dort auch einen Eintrag "Erstverbindung ins Heimnetz als:" und dort steht der Name-02 drinne... ich vermute das ist der Name den ich beim ersten Start von Trixie vergeben hatte.
Wenn ich heute mit tracert IP in einem Windows-Terminal nachschaue dann kommt dort die Rückmeldung, dass unter der IP das Gerät Name-02 ist.
Wenn ich tracert Name teste kommt das gleiche Ergebnis, mit tracert Name-02 gibt es "Name konnte nicht aufgelöst werden".
Ein ping klappt mit beiden Namen.
Wenn ich einen MQTT-Client programmiere mit dem Namen, kann keine Verbindung aufgebaut werden.
Wenn ich einen MQTT-Client programmiere mit dem Namen-02, dann wird eine Verbindung aufgebaut.
Mit IP natürlich auch.Ich vermute dass beim crash gar nix passiert ist... außer dass der neue raspi halt neu gestartet werden musste und er ab dem Zeitpunkt dann mit dieser Situation nicht mehr klarkommt... bzw. der Adapter.
Langer Rede kurzer Sinn: Ich würde mich freuen Hilfe zu bekommen die Ursache zu finden und auch zu beheben, aber das ist ja jetzt eigentlich ein anderes Thema. Ich möchte nicht einfach nur in den Clients jetzt die IPs eintragen, ich würde gerne beim Namen bleiben, daher muss ich mal herausfinden wie ich das löse.
Eine viel wichtigere Frage die hier vielleicht noch hinpasst:
Ihr habt mir ja jetzt gezeigt dass meine Platte offensichtlich Kummer hat. Wo kann ich da mehr lesen bzgl. SSD-Test, SSD-Health, Ursachen-Analyse?
An der Stelle noch ein kleiner Hinweis: Ich habe in der config.txt das pciex1_gen=3 gesetzt um die Geschwindigkeit höher zu zwingen... in einem anderen Forum wurde mir gesagt dass das alle machen und bis jetzt noch keine Schwierigkeiten bekannt sind...oder gibt es hier eine andere Meinung ?@NoPlayBack-0 sagte in MQTT Adapter does not start any more after raspi-crash:
In der Fritzbox ist nun bei den Geräteinformationen zwar der richtige Name eingetragen
Dann lösch die Doublette dort raus.
-
so, neuer Tag neues Glück:
Erst einmal vielen Dank an die super Unterstützung hier, ich weiß jetzt wo die Ursache ist, beheben konnte ich sie noch nicht.
Ich hatte beim Umbau von alt auf neu ein paar mal IPs und Namen der Netzwerkgeräte gewechselt, mit dem Ziel, dem Haupt-Raspi die gleiche IP und den gleichen Namen zu geben wie vorher.
In der Fritzbox ist nun bei den Geräteinformationen zwar der richtige Name eingetragen, aber es gibt dort auch einen Eintrag "Erstverbindung ins Heimnetz als:" und dort steht der Name-02 drinne... ich vermute das ist der Name den ich beim ersten Start von Trixie vergeben hatte.
Wenn ich heute mit tracert IP in einem Windows-Terminal nachschaue dann kommt dort die Rückmeldung, dass unter der IP das Gerät Name-02 ist.
Wenn ich tracert Name teste kommt das gleiche Ergebnis, mit tracert Name-02 gibt es "Name konnte nicht aufgelöst werden".
Ein ping klappt mit beiden Namen.
Wenn ich einen MQTT-Client programmiere mit dem Namen, kann keine Verbindung aufgebaut werden.
Wenn ich einen MQTT-Client programmiere mit dem Namen-02, dann wird eine Verbindung aufgebaut.
Mit IP natürlich auch.Ich vermute dass beim crash gar nix passiert ist... außer dass der neue raspi halt neu gestartet werden musste und er ab dem Zeitpunkt dann mit dieser Situation nicht mehr klarkommt... bzw. der Adapter.
Langer Rede kurzer Sinn: Ich würde mich freuen Hilfe zu bekommen die Ursache zu finden und auch zu beheben, aber das ist ja jetzt eigentlich ein anderes Thema. Ich möchte nicht einfach nur in den Clients jetzt die IPs eintragen, ich würde gerne beim Namen bleiben, daher muss ich mal herausfinden wie ich das löse.
Eine viel wichtigere Frage die hier vielleicht noch hinpasst:
Ihr habt mir ja jetzt gezeigt dass meine Platte offensichtlich Kummer hat. Wo kann ich da mehr lesen bzgl. SSD-Test, SSD-Health, Ursachen-Analyse?
An der Stelle noch ein kleiner Hinweis: Ich habe in der config.txt das pciex1_gen=3 gesetzt um die Geschwindigkeit höher zu zwingen... in einem anderen Forum wurde mir gesagt dass das alle machen und bis jetzt noch keine Schwierigkeiten bekannt sind...oder gibt es hier eine andere Meinung ?@NoPlayBack-0 sagte in MQTT Adapter does not start any more after raspi-crash:
pciex1_gen=3
Dazu nur:
- Gen3 is not officially supported. This is high frequency stuff, so running with Gen3 on a system laid out for Gen2 might or might not work and you are expected to get random errors.
- I am still waiting for a real-life usage-scenario that gives you an advantage with Gen3 over Gen2. And if you need this additional performance, than I question that the Pi5 is a good basis for your needs.
Würde ich also auf einem System, das stabil laufen soll und nicht als Experimentierfeld dient nicht setzen.
Ich sehe gerade, dass du dir da einen ganzen Blumenstrauß an wilden Einstellungen reingeklatscht hast. Kein Wunder, dass die Kiste seltsam läuft.
-
@NoPlayBack-0 sagte in MQTT Adapter does not start any more after raspi-crash:
pciex1_gen=3
Dazu nur:
- Gen3 is not officially supported. This is high frequency stuff, so running with Gen3 on a system laid out for Gen2 might or might not work and you are expected to get random errors.
- I am still waiting for a real-life usage-scenario that gives you an advantage with Gen3 over Gen2. And if you need this additional performance, than I question that the Pi5 is a good basis for your needs.
Würde ich also auf einem System, das stabil laufen soll und nicht als Experimentierfeld dient nicht setzen.
Ich sehe gerade, dass du dir da einen ganzen Blumenstrauß an wilden Einstellungen reingeklatscht hast. Kein Wunder, dass die Kiste seltsam läuft.
Das Feld lässt sich in der Fritzbox nicht editieren !
@Thomas-Braun sagte in MQTT Adapter does not start any more after raspi-crash:
Ich sehe gerade, dass du dir da einen ganzen Blumenstrauß an wilden Einstellungen reingeklatscht hast. Kein Wunder, dass die Kiste seltsam läuft.
What ? Wo ? Was ? Außer diesem einen Eintrag weiß ich von nix ?
-
Das Feld lässt sich in der Fritzbox nicht editieren !
@Thomas-Braun sagte in MQTT Adapter does not start any more after raspi-crash:
Ich sehe gerade, dass du dir da einen ganzen Blumenstrauß an wilden Einstellungen reingeklatscht hast. Kein Wunder, dass die Kiste seltsam läuft.
What ? Wo ? Was ? Außer diesem einen Eintrag weiß ich von nix ?
[Sat Jan 3 11:51:27 2026] Kernel command line: reboot=w coherent_pool=1M 8250.nr_uarts=1 pci=pcie_bus_safe cgroup_disable=memory numa_policy=interleave nvme.max_host_mem_size_mb=0 numa=fake=8 system_heap.max_order=0 smsc95xx.macaddr=2C:CF:67:9E:6A:69 vc_mem.mem_base=0x3fc00000 vc_mem.mem_size=0x40000000 console=ttyAMA10,115200 console=tty1 root=PARTUUID=b035d9c0-02 rootfstype=ext4 fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles cfg80211.ieee80211_regdom=DEBei mir (Allerdings ein RPI4)
[Fri Dec 26 23:39:09 2025] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_headphones=0 cgroup_disable=memory numa_policy=interleave nvme.max_host_mem_size_mb=0 snd_bcm2835.enable_headphones=1 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_hdmi=0 numa=fake=2 system_heap.max_order=0 smsc95xx.macaddr=E4:5F:01:0B:F7:93 vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000 console=tty1 root=PARTUUID=68a5cb8b-02 rootfstype=ext4 fsck.repair=yes rootwaitUnterschied: Mein System läuft stabil, deins verhält sich seltsam.
-
Nojo..... was ist schlimm ?
Ich vermute mal, Raspi4 vs Raspi5, wie gesagt, bewußt habe ich nur PCIv3 gesetzt.
-
So.... smartmontools genutzt... selftest, shorttest, alles zeigt alles ok !
Wenn die Platte Ärger macht müsste doch was in der log für die Selftest stehen?Bzgl. IP-Adresse und Netzwerknamen: Alles mögliche probiert, letztendlich half nur das Gerät in der Fritzbox löschen... da waren 3 verschiedene mit unterschiedlichen MAC drinne, was aber auch so stimmen kann.
Danach... ei guck, alles in Ordnung. Die ganze Aufregung für nix ...
-
Das Dateisystem selber hast Du schon geprüft?
Wenn beim Starten das Dateisystem bereinigt werden muss, ist vorher irgendetwas schief gegangen ...
Wird meist durch einen harten Shutdown oder Versorgungsspannungsunterbrechung verursacht...Beim regulären Herunterfahren werden alle Schreiboperationen auf das Dateisystem noch beendet, und dadurch ein sauberer Zustand hinterlassen...
Beim Irregulären Herunterfahren kann das Dateisystem beschädigt werden.Smartmontools schauen eine Ebene tiefer...
Intel(R) Celeron(R) CPU N3000 @ 1.04GHz 8G RAM 480G SSD
Virtualization : unprivileged lxc container (debian 12 on Proxmox 8.4.14)
Linux pve 6.8.12-16-pve
6 GByte RAM für den Container
Fritzbox 6591 FW 8.03 (Vodafone Leih-Box)
Remote-Access über Wireguard der Fritzbox
Support us
477
Online32.6k
Benutzer82.0k
Themen1.3m
Beiträge