Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[mcm1957]

Link zum gleichlautenden Issue: https://github.com/ioBroker/ioBroker.mqtt/issues/582

[mcm1957]

@NoPlayBack-0

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.

[NoPlayBack 0]

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....

[NoPlayBack 0]

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.

[NoPlayBack 0]

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 ?

[Thomas Braun]

@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.

[Thomas Braun]

@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]

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 ?

[Thomas Braun]

@NoPlayBack-0

[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=DE

Bei 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 rootwait

Unterschied: Mein System läuft stabil, deins verhält sich seltsam.

[NoPlayBack 0]

Nojo..... was ist schlimm ?
Ich vermute mal, Raspi4 vs Raspi5, wie gesagt, bewußt habe ich nur PCIv3 gesetzt.

[NoPlayBack 0]

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 ...

[MartinP]

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...

[Thomas Braun]

@MartinP sagte in MQTT Adapter does not start any more after raspi-crash:

Smartmontools schauen eine Ebene tiefer...

Noch dazu ist smartmontools auf ssd und nvme nur äußerst bedingt aussagekräftig.
Auf meinen Kisten verwende ich das z. B. gar nicht.

[MartinP]

Es gibt schon ein paar spezielle Smartmon Messwerte, die man für SSDs eingeführt hat. Ich lese aber nur die Restlebensdauer aus.

[NoPlayBack 0]

Ich bin gerade verwirrt wie kompliziert so ein Dateisystemscheck werden kann.
Ich schieße jetzt auf fsck, das läuft aber nicht im Normalbetrieb.
Also habe ich mit SDCard gebootet und gehofft, es wäre dann möglich.... nö.
Dann habe ich versucht mittels GParted das Laufwerk auszuhängen, kam eine Fehlermeldung.
Also habe ich

sudo fsck /dev/nvme0n1p2 -n

probiert mit dem Ergebnis:

fsck from util-linux 2.41
e2fsck 1.47.2 (1-Jan-2025)
Warning!  /dev/nvme0n1p2 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Feature orphan_present is set but orphan file is clean.
Clear? no

Dann

sudo umount /dev/nvme0n1p2

mit Erfolg.

Dann fsck noch einmal ohne -n:

fsck from util-linux 2.41
e2fsck 1.47.2 (1-Jan-2025)
/dev/nvme0n1p2: clean, 240631/15597568 files, 21604973/62381652 blocks

Das "clean" im Feedback macht mir Hoffnung....

Trotzdem, nach Reboot.... immer noch "orphan cleanup on readonly fs" und ein fsck mit -n im laufenden Betrieb zeigt wieder "Feature orphan_present is set but orphan file is clean."

[MartinP]

Vielleicht ist das eine Logmeldung, die Fehlintepretationspotential bietet.

Möglicherweise habe ich das gleiche "Problem":

[Sun Jan  4 01:51:09 2026] EXT4-fs (dm-12): write access unavailable, skipping orphan cleanup

Vielleicht bedeutet die Meldung nur, dass der Test nicht durchgeführt werden konnte, und es deshalb orphan Nodes geben KÖNNTE.

e2fsck ist ein Tool, was auch die Möglichkeit bietet, EXTx Dateisysteme zu bereinigen.

EDIT:

Falls es etwas zu bereinigen gegeben hat, muss das Logging wahrscheinlich z.B. so aussehen:

[9240990.133326] EXT4-fs (dm-21): orphan cleanup on readonly fs
[9240990.166215] EXT4-fs (dm-21): 6 orphan inodes deleted
[9240990.423904] EXT4-fs (dm-21): recovery complete

Meldung 1 ist der Hinweis, was gerade gemacht wird.
Meldung 2 kommt nur, wenn es etwas zu bereinigen gab.

[Homoran]

@MartinP sagte in MQTT Adapter does not start any more after raspi-crash:

so aussehen:

und genau so steht es in iob diag

[MartinP]

Zeile 2 und 3 meines Log-Schnipsels habe ich dann wohl im diag output überlesen...

Meine Theorie.
"orphan cleanup on readonly fs" Alleine -> Dateisystem war o.k.
Zusätzlich
"xxx orphan inodes deleted" und "recovery completed" -> Es gab etwas zu tun.

[MartinP]

sagte in MQTT Adapter does not start any more after raspi-crash:

Zeile 2 und 3 meines Log-Schnipsels habe ich dann wohl im diag output überlesen...

Meine Theorie.
"orphan cleanup on readonly fs" Alleine -> Dateisystem war o.k.
Zusätzlich
"xxx orphan inodes deleted" und "recovery completed" -> Es gab etwas zu tun.

Wenn man sich anschauen will, ob irgendwann in der kürzlichen Vergangenheit inodes aufgeräumt wurden, kann man in /var/log/boot.log.* die letzten acht Boots inspizieren.

martin@martin-D2836-S1:~/gitea/Knowledgebase$ ls -l /var/log/boot.*
-rw------- 1 root root     0 Dez 31 00:00 /var/log/boot.log
-rw------- 1 root root  5225 Dez 31 00:00 /var/log/boot.log.1
-rw------- 1 root root 99431 Dez 30 10:55 /var/log/boot.log.2
-rw------- 1 root root 20734 Dez 29 13:21 /var/log/boot.log.3
-rw------- 1 root root 30312 Dez 24 00:00 /var/log/boot.log.4
-rw------- 1 root root 25988 Dez 23 10:23 /var/log/boot.log.5
-rw------- 1 root root 15901 Dez 19 10:00 /var/log/boot.log.6
-rw------- 1 root root 51000 Dez 18 10:16 /var/log/boot.log.7

Ergebnis

martin@martin-D2836-S1:~/gitea/Knowledgebase$ sudo grep "orphan" /var/log/boot.*
/var/log/boot.log.2:/dev/sdb2: Clearing orphaned inode 1048606 (uid=0, gid=0, mode=0100644, size=584)
/var/log/boot.log.2:/dev/sdb2: Clearing orphaned inode 6160406 (uid=0, gid=0, mode=0100644, size=48880)

Vor dem Boot am 30 Dezember hat es wohl einen nicht ordnungsgemäßen shutdown gegeben.

[Homoran]

@MartinP sagte in MQTT Adapter does not start any more after raspi-crash:

Meine Theorie.
"orphan cleanup on readonly fs" Alleine -> Dateisystem war o.k.

sehe ich anders, habe aber nicht die notwendige Expertise
für mich heisst das, orphans vorhanden, konnten aber wieder repariert werden

hier
@MartinP sagte in MQTT Adapter does not start any more after raspi-crash:

orphan inodes deleted

war keine Reparatur möglich