@tourer4778
Kurz zu deiner Rückfrage in #25 – mein „abwarten“ in #24 war zu knapp.
Gemeint war: Erst wenn das Journal wirklich persistent auf der SSD landet, lohnt es sich, auf den nächsten ungeplanten Neustart zu warten und mit journalctl -b -1 zu schauen, was direkt davor passiert ist (Freeze/Watchdog/Strom vs. geplanter Reboot). Solange fast alles nur unter /run/log/journal (RAM) liegt, sind neuere Einträge nach einem Reboot wieder weg – passt zu „heute Morgen noch aktueller, jetzt fehlt wieder was“, besonders nach deinem manuellen Neustart.
In #25 steht der Knackpunkt im journald-Log:
Assignment outside of section. Ignoring.
Dann wird Storage=persistent nicht angewendet (Zeile außerhalb von [Journal], oft ganz oben in journald.conf). In #23 war /etc/systemd/journald.conf.d/ leer – das Drop-in fehlt dort noch.
Vorschlag:
sudo nano /etc/systemd/journald.conf
Oben kein Storage=…; unter [Journal] reichen die Defaults (#Storage=auto).
sudo mkdir -p /etc/systemd/journald.conf.d
sudo nano /etc/systemd/journald.conf.d/persistent.conf
Inhalt:
[Journal]
Storage=persistent
sudo systemctl restart systemd-journald
logger "Journal-Test $(date)"
sudo journalctl -u systemd-journald -n 25 --no-pager
sudo ls -la /var/log/journal/*/
sudo journalctl --disk-usage
Erfolg: Meldungen wie „System Journal (/var/log/journal/...)“ / „flushing to /var/log/journal“, Dateien mit heutigem Datum, kein „Assignment outside of section“.
sudo touch /var/log/journal/.write-test && sudo rm /var/log/journal/.write-test
Wenn das steht – beim nächsten ungeplanten Neustart bitte:
sudo journalctl -b -1 -n 200 --no-pager
Speicher (#25): ~6,3 GB belegt, js-controller ~676 MB – zweite Baustelle; Journal zuerst, sonst beim nächsten Crash wieder keine Belege.
mit KI aus dem Thread zusammengefasst