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

[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

[MartinP]

war keine Reparatur möglich

Soweit ich weiß, ist Reparatur beim Booten zumindest bei EXTx Dateisystemen nicht vorgesehen...

"Orphaned" = Verwaiste inodes werden beim Booten gelöscht, und nicht heuristisch angeklebt, wo das Filesystem meint, dass das Puzzleteil hingehört ...

Es gibt aber die Möglichkeit, die Orphaned Nodes als Dateien in /lost+found/ ablegen zu lassen...

Dann kann man sich nach dem Booten mit Tools an die Arbeit machen, die Puzzlestücke Dateien zuzuordnen

[NoPlayBack 0]

Wenn ich richtig gelesen habe ist ein Flag gesetzt, dass es orphaned gibt, aber im Orphan-File in der die dann gelistet sein müssten steht nix.
Mein einziges Restproblem ist jetzt nur, dass fsck dann nachfragen müsste ob er das Flag löschen darf... aber das bekomme ich nicht hin. Jedenfalls nicht mit SDCard booten und dann von dort auf die SSD zuzugreifen.
Nu gut... muss ich mit leben.

Ich versuche mal jetzt noch

sudo shutdown -F -r now

und der macht genau.... nix.

[Homoran]

@NoPlayBack-0 und sudo halt -p ?

[NoPlayBack 0]

halt -p stopped das System und schaltet aus , richtig?

Ich verstehe nicht genau wo es dann hingehen soll?
Vorher sudo touch /forcefsck damit er dann prüft, oder danach mit SDCard booten ?

[NoPlayBack 0]

Mal eine Frage an die Fachleute... was mich gerade umtreibt... raspiBackup vom Typ tar erzeugt ja eigentlich eine Dateisicherung aller Dateien auf den Partitionen, und beim Restore werden die Partitionen hergestellt und dann die Dateien kopiert.
Dabei müssten doch auch automatisch vorher vorhandene Dateisystemfehler verschwinden? Es wird ja wieder das Dateisystem genutzt um vermeintlich saubere Dateien zurück auf die Partition zu kopieren? Also könnte raspibackup gar keinen Dateisystemfehler per Backup wieder herstellen ?

[mcm1957]

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

Mal eine Frage an die Fachleute... was mich gerade umtreibt... raspiBackup vom Typ tar erzeugt ja eigentlich eine Dateisicherung aller Dateien auf den Partitionen, und beim Restore werden die Partitionen hergestellt und dann die Dateien kopiert.
Dabei müssten doch auch automatisch vorher vorhandene Dateisystemfehler verschwinden? Es wird ja wieder das Dateisystem genutzt um vermeintlich saubere Dateien zurück auf die Partition zu kopieren? Also könnte raspibackup gar keinen Dateisystemfehler per Backup wieder herstellen ?

Ja seh ich auch so

EDIT:
Allerdings kann kein Backup DEFEKTE Dateien reparieren. Sprich wenn das Backup erst erstellt wurde nachdem was kaputt gegangen ist, kann das kein Backup reparieren. Da kann denn schon mal eine Datei auch nur halb restauriert werden.

[NoPlayBack 0]

Ja klar.

[NoPlayBack 0]

So, habe jetzt mal die Platte an einem anderem 4er raspi getauscht, läuft mit USB-SSD.
Trixie-SDCard über Raspi-Imager erzeugt, paar Einstellungen gemacht, gparted gnome und raspibackup drauf. Dann per SDCard-Kopier auf die SSD gezogen und laufen gelassen.
Im journalctl direkt zu sehen:

EXT4-fs (sda2): orphan cleanup on readonly fs

Sieht mir langsam wie ein Standard-Eintrag beim Booten aus...