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

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

[Thomas Braun]

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

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

Hier gibt es solche Einträge nicht. Und schon gar nicht als 'Standard'.