Ist ein "normaler" Intel Desktop PC(10.Gen) mit Debian Bullseye. Keys sind gelöscht. Passiert mit und ohne Key. In grub "intel_iommu=off iommu=soft" oder mit Hardware-Iommu macht auch keinen Unterschied. "security_lockdown_lsm_early lockdown=confidentiality"(secureboot) ist auch noch aktiviert und möchte ich ungern herausnehmen, das hatte auch nie wirklich Probleme bereitet.
Ich habe gerade wieder das korrupte Log direkt nach dem Start, vor dem Ausschalten hatte ich noch "--verify" durchlaufen lassen, da war das Log okay(ohne Secret-Key).
Ich habe halt keine Ahnung wie ich das deuten soll, ist das bedenklich?
Code: Alles auswählen
systemctl list-units|grep journal
systemd-journal-flush.service loaded active exited Flush Journal to Persistent Storage
systemd-journald.service loaded active running Journal Service
systemd-journald-audit.socket loaded active running Journal Audit Socket
systemd-journald-dev-log.socket loaded active running Journal Socket (/dev/log)
systemd-journald.socket loaded active running Journal Socket
Code: Alles auswählen
journalctl --verify
390438: Data object references invalid entry at 53af38
File corruption detected at /var/log/journal/8bu.../user-1000.journal:53add0 (of 8388608 bytes, 65%).
FAIL: /var/log/journal/8bu.../user-1000.journal (Ungültige Nachricht)
PASS: /var/log/journal/8bu.../system.journal
Was mir in dem Log auffällt ist folgendes, davon gibt es sehr viele Einträge:
Code: Alles auswählen
org.gnome.SettingsDaemon.Sound.service: Succeeded.
Mär 14 10:11:32 user gnome-shell[919]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
Mär 14 10:11:32 user gnome-shell[919]: == Stack trace for context 0x55da5eacd150 ==
Mär 14 10:11:32 user gnome-shell[919]: == Stack trace for context 0x55da5eacd150 ==
Mär 14 10:11:32 user gnome-shell[919]: == Stack trace for context 0x55da5eacd150 ==
Mär 14 10:11:32 user gnome-shell[919]: == Stack trace for context 0x55da5eacd150 ==
Mär 14 10:11:32 user gnome-shell[919]: == Stack trace for context 0x55da5eacd150 ==
Mär 14 10:11:32 user gnome-shell[919]: == Stack trace for context 0x55da5eacd150 ==
Mär 14 10:11:32 user gnome-shell[919]: == Stack trace for context 0x55da5eacd150 ==
Mär 14 10:11:32 user gnome-shell[919]: == Stack trace for context 0x55da5eacd150 ==
Mär 14 10:11:32 user gnome-shell[919]: == Stack trace for context 0x55da5eacd150 ==
Mär 14 10:11:32 user gnome-shell[919]: The offending signal was destroy on Gjs_ui_appDisplay_FolderGrid 0x55da60c80f70.
...
Mär 14 10:24:00 user gnome-shell[1864]: == Stack trace for context 0x558f0d755150 ==
Mär 14 10:24:00 user gnome-shell[1864]: The offending signal was destroy on Gjs_ui_appDisplay_AppIcon 0x558f0f64f510.
Mär 14 10:24:00 user gnome-shell[1864]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.