debian 12 Bookworm - Fehlersuche/Logs

Hallo Allerseits,

habt Ihr ein paar Hinweise für mich, wo ich Logs finde mit Fehlern und Mängeln im Boot-/Startvorgang von Debian 12 Bookworm (systemd in UEFI/GPT-System) und Cinnamon? Seitdem ich nun zwei parallele Debian-Installationen und eine Windows 10 Installation auf dem Notebook habe, habe ich mir bei den Debian-Systemen eine 60sekündige Pause in die Bootprozessen eingefangen.

Die erste Debian-Installation habe ich mit vielen missgückten Installationsversuchen irgendwie ein bischen vermurkst: Cinnamon hängt dort nach jedem Systemstart ohne Leisten (nur Hintergrund sichtbar), läuft aber nach einem "Neustart" per [Strg]+[Alt]+[Esc] unauffällig.

Ich brauche in paar Tipps, wo ich beteiligte log-Dateien finde, welche am relevantesten sind und ganz toll wäre ein praxiserprobter Tipp darüber, wie ich herausfinde, welche Logs in meinem System relevant sind.

Einiges habe ich schon selbst herausgefunden & repariert (die zweite Debian-Installlation war nicht so gesund für Grub), usw.. UEFI funktioniert inzwischen endlich (hat ja auch nur 10 Jahre gedauert), scheint aber tendenziell zu kompliziert zu sein: Die meisten Tools und Rezepte (bezüglich UEFI) sind ziemlich unzureichend/irreführend beschrieben/realisiert- das erfordert viel Geduld (und Nervenstärke, weil man erstmal nicht mehr an das System herankommt).

Hintergrund:

Kürzlich bin ich mal wieder auf Linux umgestiegen (inspiriert von Jean's Debian-Videos, Danke dafür ). Nach vielen Stunden in denen ich mir für meine Arbeit (Netzwerkadministration, vorwiegend Windows/Windows Server, Router, Firewalls, etc.) benötigte ich einiges, aber unterm Strich wohl nicht allzu viel. Bei meinem letzten Versuch vor gut 10 Jahren habe ich auch für gut zwei Jahre mit Linux gearbeitet und bin bei den OpenSource-Anwendungen (LibreOffice-Suite, Firefox, Thunderbird, Gimp, VLC) auch danach unter Windows geblieben.

Zitat von A.E.

Die meisten LOG Dateien wirst Du im /var/log Verzeichnis Deiner Distribution finden.

OK, habe da (/var/log) mal drin "herumgestöbert". Die boot.log fängt leider erst spät an den Bootprozess mitzuprotokollieren, aber ziemlich genau an der Stelle, nachdem die Boot-Pause (~30 Sekunden) eintritt:

/var/etc/boot.log:
--------------------------------------------------------------------------------
Gave up waiting for suspend/resume device
/dev/nvme0n1p4: clean, 569038/2093056 files, 5712571/8388608 blocks
...

Mein System scheint nach irgendeinem Gerät zu suchen und gibt die Suche nach 30 Sekunden auf. (Ich frage mich da: Wer sucht da nach welchem Gerät und will/brauche ich das?)

Der fschk über /dev/nvme0n1p4 wird bei jedem Start ausgeführt. Das ist meine root (/) und läuft unmerklich schnell durch. Ist das normal, dass bei jedem Start ein fsck auf root durchgeführt wird?

Bezüglich des Cinnamon-Fehlers (erfolgloser Start nach jedem Anmelden, braucht einmal [Strg]+[Alt]+[Esc]) werde ich in den log-Dateien zwar nicht fündig, aber unter /var/log liegt eine auffällige README und die erklärt, dass systemd-basierte Systeme andere Logs schreiben und dass man sich die mit dem Befehl journalctl anschaut. journalctl zeichnet anscheinend den Cinnamon-Start auf, und zwar abhängig vom Benutzer: Jeder Benutzer hat seine eigenen Inhalte von journalctl.

Damit komme ich weiter.

Zitat von Bundy

Kaenguru73 in Sachen "Gedenkminute": gave up waiting for suspend/resume device könnte darauf hindeuten, dass versucht wird, eine nicht (mehr) vorhandene Partition zu mounten. Möglicherweise hat sich bei der Installation des zweiten Debian die UUID einer Partition (z.B. swap) geändert. Gibt es diese "Gedenkminute" auf beiden Installationen?

Ja, darüber habe ich auch einiges gelesen und Swap in beiden Installationen deaktiviert & reaktiviert. (Bin selbst schuld: Ich hatte anfangs probiert, dieselbe swap-Partition für beide Installationen zu verwenden - bad idea.) Das sollte es nicht sein. Habe gerade nochmal in /etc/fstab reingeguckt - device und uuid stimmen mit den Angaben in gparted überein. Die fstab gilt doch nach wie vor, oder gibt es da inzwischen auch irgendeine Erweiterung?

Zitat von Bundy

Ja, die fstab ist nach wie vor relevant; die UUID der Swap-Partition steht aber auch noch in der /etc/initramfs-tools/conf.d/resume

Das war es: In /etc/initramts-tools/conf.d/resume stand eine nicht mehr aktuelle UUID drin (RESUME=UUID=.....). Mit den Anweisungen aus dem von Dir verlinkten Artikel:

Zitat von Bundy

https://unix.stackexchange.com/questions/3683…s/473884#473884

Also

sudo nano /etc/initramts-tools/conf.d/resume

Dann die eine Zeile auf RESUME= ändern und speichern. (sudo echo "RESUME=" >/etc/initramts-tools/conf.d/resume scheitert: keine Berechtigung).

mit

sudo update-initramfs -u

muss die Konfiguration geändert werden (dauert kurz). Danach zeigt uns

sudo cat /etc/initramts-tools/conf.d/resume

dass der Inhalt nicht geändert wurde. Entsprechend der vorhergehenden Bildschirmausgabe sollte die UUID der swap-Partition eingetragen werden. Die erhält man per

sudo cat /etc/fastab

Ich habe die mit der Maus im graphischen Terminal merkiert, über das Kontext-Menü kopiert. Danach kann die UUID mit Hilfe von nano eingetragen werden (per Mausrad-Klick):

sudo nano /etc/initramts-tools/conf.d/resume

Der anschließende Neustart hat keine 30 Sekunden-Pause mehr!

------------------------------------------------------------------------------

Zitat von Bundy

Ansonsten sind wir möglicherweise auch komplett auf dem Holzweg - dann ist intensives Studium der Ausgabe von sudo journalctl angesagt...

Das ^Journal habe ich gesucht, aber das ist so quasi unzumutbar - muss ich erst lernen. Die neuesten Einträge stehen unten und mit [Ende] passiert garnichts, mit [Strg]+[Ende] beendet man journalctl... Folglich stehe ich ewig auf der Page-Down-Taste... Das erfordert man-page-Studium... Aber nach der langen Suche habe ich mit bloßen Augen nichts darin gefunden, auch nicht die 30sekündige Pause. Aber das muss nichts heißen.

Vielen Dank! und nochmal vielen Dank!