[Gelöst] Verzögerter Bootvorgang: UUID der swap-Partition offensichtlich falsch - mein Lösungsweg richtig?

[prox]

Hi,

mein Laptop hat sich mal wieder verschnupft, er schrömmelt jetzt beim Booten was rum. Aufgrund der Installation einer zweiten Linux-Distribution (nennen wir sie mal so) namens KDE neon, hier: die User Edition, neben das bereits installierte Debian 12.

Durch die Installation von KDE neon löschte ich die bis dahin vorhandene Installation von Linux Mint Debian Edition 6 (LMDE 6). Das heißt, dass ich bei der Installation von KDE neon angegeben hatte, Grub2 nicht zu installieren. Da Grub2 ja schon Bestandteil der anderen Linux-Distribution in meinem Laptop, nämlich Debian 12, ist.

Ich installierte also KDE neon komplett, aber ohne Grub2, in die Partition, in der vorher das Verzeichnis "/" unter LMDE 6 eingehängt gewesen war.

Nach der Installation von KDE neon startete ich Debian 12 und führte als root den Befehl "update-grub" aus.

Seitdem ist der Bootvorgang von KDE neon stets erfolgreich.

Der Bootvorgang von Debian 12 bis zum grafischen Login in KDE dauert seit der Installation von KDE neon jetzt allerdings erheblich länger:

Zuerst erscheint beim Booten von Debian 12 auf dem schwarzen Bildschirm am oberen Bildschirmrand folgende Meldung:

Gave up waiting for suspend/resume device

Danach, nach einer gewissen Weile, werden nacheinander die typischen Boot-Meldungen von Debian 12 ausgegeben, deren einzelnen Zeilen jeweils mit einem in grüner Schriftfarbe gehaltenen "OK" beginnen.

Bis eine Zeile ausgegeben wird, die sinngemäß besagt, dass der Ausführung eines "Jobs" 130 Sekunden Zeit gegeben werden. Nachdem diese 130 Sekunden heruntergezählt worden sind, wird der Bootvorgang fortgesetzt, bis der grafische Login zu KDE erscheint. Der Login in KDE ist wie gewohnt erfolgreich.

Diese Zeile, die während des Bootvorgangs auf dem Bildschirm ausgegeben wird und sich auf den genannten "Job" bezieht, kann sich laut der Ausgabe des Befehls "journalctl -b" nur auf folgende Vorgänge beziehen:

Code: Alles auswählen

[...]
Mär 01 11:01:29 xxx systemd[1]: systemd-rfkill.service: Deactivated successfully.
Mär 01 11:01:51 xxx systemd[1]: systemd-fsckd.service: Deactivated successfully.
Mär 01 11:02:41 xxx systemd[1]: dev-disk-by\x2duuid-d052e56a\x2d9c87\x2d4aed\x2d890f\x2d032f65734cf3.device: Job dev-disk-by\x2duuid-d052e56a\x2d9c87\x2d4aed\x2d890f\x2d032f65734cf3.device/start timed out.
Mär 01 11:02:41 xxx systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-d052e56a\x2d9c87\x2d4aed\x2d890f\x2d032f65734cf3.device - /dev/disk/by-uuid/d052e56a-9c87-4aed-890f-032f65734cf3.
Mär 01 11:02:41 xxx systemd[1]: Dependency failed for dev-disk-by\x2duuid-d052e56a\x2d9c87\x2d4aed\x2d890f\x2d032f65734cf3.swap - /dev/disk/by-uuid/d052e56a-9c87-4aed-890f-032f65734cf3.
Mär 01 11:02:41 xxx systemd[1]: Dependency failed for swap.target - Swaps.
Mär 01 11:02:41 xxx systemd[1]: swap.target: Job swap.target/start failed with result 'dependency'.
Mär 01 11:02:41 xxx systemd[1]: dev-disk-by\x2duuid-d052e56a\x2d9c87\x2d4aed\x2d890f\x2d032f65734cf3.swap: Job dev-disk-by\x2duuid-d052e56a\x2d9c87\x2d4aed\x2d890f\x2d032f65734cf3.swap/start failed with result 'dependency'.
Mär 01 11:02:41 xxx systemd[1]: dev-disk-by\x2duuid-d052e56a\x2d9c87\x2d4aed\x2d890f\x2d032f65734cf3.device: Job dev-disk-by\x2duuid-d052e56a\x2d9c87\x2d4aed\x2d890f\x2d032f65734cf3.device/start failed with result 'timeout'.
Mär 01 11:02:41 xxx systemd[1]: Reached target sysinit.target - System Initialization.
Mär 01 11:02:41 xxx systemd[1]: Started cups.path - CUPS Scheduler.
[...]

Hier fällt mir die UUID "d052e56a-9c87-4aed-890f-032f65734cf3" auf. Sie wird oben zwei Mal genannt. Das Ganze hat mit der Swap-Partition zu tun. Irgendeine "Dependency" kann nicht erfüllt werden, deswegen tritt in diesem Zusammenhang ein Timeout auf, welcher den Bootvorgang verzögert.

In der /etc/fstab meiner Debian-12-Installation ist die UUID "d052e56a-9c87-4aed-890f-032f65734cf3" als swap-Partition definiert:

Code: Alles auswählen

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=da76c860-7eaa-4f9b-85af-35ea612e418b /               ext4    errors=remount-ro 0       1
# /home was on /dev/sda2 during installation
UUID=2f3801ad-448c-45c0-85d3-89e86f3090b9 /home           ext4    defaults        0       2
# swap was on /dev/sda3 during installation
UUID=d052e56a-9c87-4aed-890f-032f65734cf3 none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

Hier übrigens die Partitionstabelle auf meinem Laptop:

Code: Alles auswählen

root@xxx:~# lsblk -f
NAME   FSTYPE FSVER LABEL    UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1 ext4   1.0            da76c860-7eaa-4f9b-85af-35ea612e418b  245,2G     5% /
├─sda2 ext4   1.0            2f3801ad-448c-45c0-85d3-89e86f3090b9   77,5G     2% /home
├─sda3 swap   1     SWAP     1a7ec593-9cf6-47a8-85d1-ff04d7354574
├─sda4
├─sda5 ext4   1.0            3497c9fa-a384-4f7b-bd36-df95b7e14ff0
└─sda6 ext4   1.0   OS2_ROOT aceedb50-02d8-4296-942c-3b5b5a0466cf
sr0
root@xxx:~#

Da springt es mir ja geradezu ins Auge:

In der Ausgabe des Befehls "lsblk -f" ist für die swap-Partitition die UUID "1a7ec593-9cf6-47a8-85d1-ff04d7354574" angeben, die sich ja kolossal (hihi) unterscheidet von der UUID der swap-Partition, die in der Datei /etc/fstab genannt ist. Die UUID der swap-Partition in der /etc/fstab lautet aktuell "d052e56a-9c87-4aed-890f-032f65734cf3".

Soll ich also in der /etc/fstab einfach die dort aktuell genannte UUID "d052e56a-9c87-4aed-890f-032f65734cf3" für die swap-Partition ersetzen durch die UUID "1a7ec593-9cf6-47a8-85d1-ff04d7354574", danach "update-grub" ausführen und dann mal schauen, ob der hier beschriebene Fehler beim Booten von Debian 12 nicht mehr auftritt?

[niemand]

Soll ich also in der /etc/fstab einfach die dort aktuell genannte UUID "d052e56a-9c87-4aed-890f-032f65734cf3" für die swap-Partition ersetzen durch die UUID "1a7ec593-9cf6-47a8-85d1-ff04d7354574"

Ja. Mehr sollte auch nicht notwendig sein. Vielleicht noch ein ›mkswap /dev/disk/by-uuid/1a7ec593-9cf6-47a8-85d1-ff04d7354574 darauf ausführen, um sicherzustellen, dass die Partition das richtige Format hat. Zur Sicherheit vorher aber nochmal genau prüfen, ob das keine Datenpartition ist, der nur jemand mit einem seltsamen Humor das Label „SWAP“ gegeben hat.

[prox]

Soll ich also in der /etc/fstab einfach die dort aktuell genannte UUID "d052e56a-9c87-4aed-890f-032f65734cf3" für die swap-Partition ersetzen durch die UUID "1a7ec593-9cf6-47a8-85d1-ff04d7354574"

Ja. Mehr sollte auch nicht notwendig sein. Vielleicht noch ein ›mkswap /dev/disk/by-uuid/1a7ec593-9cf6-47a8-85d1-ff04d7354574 darauf ausführen, um sicherzustellen, dass die Partition das richtige Format hat. Zur Sicherheit vorher aber nochmal genau prüfen, ob das keine Datenpartition ist, der nur jemand mit einem seltsamen Humor das Label „SWAP“ gegeben hat.

OK, Danke für die Bestätigung, ich setze das gleich mal um und melde mich dann nach dem nächsten Reboot hier wieder.

[prox]

So. Neustart durchgeführt.

Die Bootmeldung mit dem Timeout für diesen "Job" ist jetzt weg, das ist gut. Dadurch ist der Bootvorgang wieder schon ein Stück schneller. Vielen Dank für Deine Bestätigung, @niemand.

Aber die oben genannte andere Meldung, die vor dieser "Job"-Meldung auf dem schwarzen Bildschirm ausgegeben wird, die wird weiterhin ausgegeben, also diese hier:

Gave up waiting for suspend/resume device

Bis diese Meldung erscheint, dauert es sicherlich um die 15 Sekunden, also bedeutet die Ursache für diese Meldung auch eine Verzögerung des Bootvorgangs.

In den Ausgaben des Befehls "dmesg" und "journalctl -b" (bezieht sich auf den letzten Bootvorgang) gibt es keinerlei Treffer zu den Begriffen "suspend" und "resume".

Jemand eine Idee, wie ich diese Meldung wieder wegkriege?

[slu]

Stimmt hier die UUID?
/etc/initramfs-tools/conf.d/resume

ggf. update-initramfs -u ausführen.

[prox]

Stimmt hier die UUID?
/etc/initramfs-tools/conf.d/resume

ggf. update-initramfs -u ausführen.

Vielen Dank, @slu - das hat gewirkt - ja, die UUID war in der Datei /etc/initramfs-tools/conf.d/resume die falsche. Habe sie ersetzt durch die richtige (die neue) UUID, dann "update-initramfs -u" und danach sicherheitshalber noch mal ein "update-grub" ausgeführt.

Jetzt bootet mein Laptop wieder genau so schnell wie früher, also wie vor der Installation von KDE neon

Ist das nun ein Bug, der hier vorliegen könnte? Also, dass durch die Installation von KDE neon für die swap-Partition eine neue UUID generiert und in die Partitionstabelle eingetragen wurde, und die UUID für den swap in der /etc/fstab deswegen nicht mehr gestimmt hat? Soll ich das den Macher:innen von KDE neon melden?

[ernohl]

Ist das nun ein Bug, der hier vorliegen könnte? Also, dass durch die Installation von KDE neon für die swap-Partition eine neue UUID generiert

Ich denke, eher ein Feature. Wenn ich mich richtig erinnere, generiert auch der Debian-Installer neue UUIDs für die von ihm angefassten Partitionen.

[rhHeini]

Geh mal davon aus das jede Linux-Distro eine frei zugängliche Swap-Partition bei der Installation neu formatiert.

Wenn Du das bei Multiboot verhindern willst musst Du die Swap entweder verschlüsseln oder in ein LVM verpacken.

[prox]

OK, Danke für Eure Antworten. Ich glaube, bei der Installation von KDE neon hatte ich bei der Partionierung angegeben, dass die bereits vorhandene Swap-Partition formatiert werden sollte - falls dem so war, wurde dadurch natürlich (?) eine neue UUID für die Swap-Partition erzeugt.

Aber ich glaube, bei der Installation davor (Installation von LMDE 6 + daneben mein bereits installiertes Debian 12) bin ich auch so vorgegangen, hatte aber nach Abschluss dieser Installation nicht die Probleme wie hier in diesem Thread beschrieben.

[niemand]

Aber ich glaube, bei der Installation davor (Installation von LMDE 6 + daneben mein bereits installiertes Debian 12) bin ich auch so vorgegangen, hatte aber nach Abschluss dieser Installation nicht die Probleme wie hier in diesem Thread beschrieben.

Möglicherweise steht da dann /dev/sda… in der fstab, oder es wird das Label genutzt. Wenn ich ’ne Swappartition haben wollte, würde ich vermutlich auf Label setzen.

[ernohl]

Wenn Du das bei Multiboot verhindern willst musst Du die Swap entweder verschlüsseln oder in ein LVM verpacken.

Swap in ein LV? Das stelle ich mir herausfordernd vor.
Mir erscheint es einfacher, den swap im neuen System nicht bei der Installation zu definieren, sondern erst danach. Ob es sinnvoll ist, 2 Systemen die gleiche swap-Partition zuzuweisen, hängt vom Thema suspend-to-disk ab.

[rhHeini]

Da ist nichts dran herausfordernd. Mach ich standardgemäss bei fast jeder Installation, wird vom Installer unterstützt. In der Regel ein luks-Container, dadrin ein LVM für / und swap (/home liegt immer auf einem eigenen Drive). Ausnahmen bestätigen die Regel.