Armbian bleibt hängen mit Received client request to flush runtinme journal/ reliqnquish

Vorschlag: Livesystem von CD oder USB-Stick booten und dann:

mount /path/to/problem /mnt mount --make-rslave --rbind /proc /mnt/proc mount --make-rslave --rbind /sys /mnt/sys mount --make-rslave --rbind /dev /mnt/dev mount --make-rslave --rbind /run /mnt/run

chroot /mnt /bin/bash

und dann entweder: journalctl --vacuum-time=2d oder: journalctl --vacuum-size=200M

Werte (Zeit/Dateigröße) ggf. nach Wunsch anpassen.

Dann sollte das Journal aufgeräumt sein, danach Neustart des Originalsystems.

Hi,

danke.

Ich habe jetzt einfach mal blauäugig versucht die journalctl-Befehle in der Recovery-Konsole auszuführen, ging jetzt schnell. Lt. Anzeige wurden 0B entfernt und natürlich und wie nicht anders zu erwarten hat das ganze nicht funktioniert. Weil ich aber jetzt nachgeschaut habe, was journalctl tut, habe ich auch mal

1

journalctl --disk-usage

eingetippt: 5,5M werden belegt.

Muss ich mir morgen mal versuchen die Zeit zu nehmen, das so wie du vorgeschlagen hast mit einem Live-BS zu machen.

Rückfrage: "/path/to/problem" ist das Rootverzeichnis der Systemplatte mit dem Problembehafteten System?

Und damit ich nicht dumm sterben muss: Was wäre die Vermutung welches Problem mein System hat und was macht deine Problemlösung - also der mount-Part davon.

VG

Matthias S. schrieb:

"/path/to/problem"

Ja, das ist Deine Partition des Armbian, eventuell sowas wie /dev/sda1. Ich gehe mal davon aus, dass Du eine Standardinstallation mit einem Filesystem (ggf. noch swap) hast, so dass damit alles gemountet wird.

Die Befehle mit "mount --make-rslave --rbind" hängen die notwendigen Pseudodateisysteme des gebooteten Systems auch in das System unter /mnt ein.

chroot wechselt dann in dieses System, nun bezieht sich / auf das bisherige /mnt.

Nun finden dann die Recoverybefehle das Journal, weil nun alles so aussieht, wie in Deinem System, wenn es sauber hochgekommen ist.

Wenn es dann nochmal Fehlermeldungen gibt, kannst Du aus dieser Umgebung Dich ans weitere Reparieren machen. Das Problem mit dem Journald von systemd ist, dass dieser sich einen -gerade auf kleinen Systemen- zu großen Kuchen vom Filesystem gönnt, und sich dann durch den ein- oder anderen Dateisystemfehler verschluckt.

Daher kann es auch sinnvoll sein, vor dem Einhängen der Partition nach /mnt das Filesystem einem fsck zu unterziehen.

fsck -V /path/to/problem

Dann müssten die journalctl-Befehele doch aus der Recovery-Console heraus auch funktionieren?

So... Fehler ist gefunden, aber an ganz anderer Stelle:

Da gibts ein Problem mit meiner ein paar Tage alten "neuen" FritzBox (7530): die Namensauflösung funktioniert plötzlich nicht korrekt und irgendwie hat die Kiste wohl gleichzeitig eine neue IP-bekommen oder so.

Konkret: bis dato war die Kiste unter shc.fritz.box erreichbar. Angepingt wird mit dem Alias jetzt die IP .43. Die Fritze hat dem Gerät "shc" jetzt aber die IP-Adresse .84 gegeben. Ist auch auf allen Geräten hier im Netz ähnlich.

Hat aber mit der neuen Fritze schon funktioniert. Ich wage zu behaupten, dass die Fritze vor kurzem auf FritOS 8 irgendwas geupdatet und das Problem seitdem besteht.

Und nu?