Habe ein Debian-basiertes Linux, das einige Male hardwaregeklont wurde. Obwohl es eine SSD hat, kommt es zu langen Startverzögerungen.
Ursprünglich gab es ein kleines, sich langsam drehendes Symbol, das anzeigte, dass auf einen Job gewartet wurde, bevor die Zeit abgelaufen war. Dafür fand ich eine in /etc/fstab referenzierte Auslagerungsdatei, die eigentlich nicht existierte, also löschte ich die Zeile mit der entsprechenden UUID und der „Job/Timeout“-Fehler verschwand …
...aber wurde durch einen langen leeren Bildschirm mit blinkendem Cursor ersetzt, auf dem eine Meldung blinkt, bevor die Anmeldeaufforderung angezeigt wird. Die blinkende Meldung lautet:
Gave up waiting on suspend/resume device.
/dev/sda1 [some disk metrics here]
/dev/sda1 ist laut gparted die einzige Partition, die existiert. Ich versuche, diese lange Startverzögerung zu beheben und die Ursache für das Warten zu finden. Für jede Hilfe wäre ich dankbar. Danke!
BEARBEITEN: Ich habe versucht, basierend auf dieser Antwort eine Auslagerungsdatei neu zu erstellen: https://superuser.com/questions/1204627/deleted-a-partition-now-getting-gave-up-waiting-for-suspend-resume-device-mes/1204634aber es trat die gleiche Verzögerung auf, nur änderte sich die Fehlermeldung in „ein Problem mit der Journalführung“ – es geht zu schnell, als dass ich es erkennen könnte. – Also löschte ich einfach die SWAP-Datei und kommentierte ihren Verweis in /etc/fstab, was mich wieder zum obigen Problem zurückbrachte.
Antwort1
Passiert nach dem Löschen der swapPartition
Wenn eine swapPartition gelöscht wird (z. B. absichtlich bei der Migration von HD auf SSD), /etc/initramfs-tools/conf.d/resumesollte die Datei entweder vollständig leer oder lesbar sein RESUME=. „Beliebige UUIDZahl löschen RESUME=NONE“ ist ungültig.
$ sudo gvim /etc/initramfs-tools/conf.d/resume
Deranfängliches RAM-Dateisystemerfordert eine Aktualisierung, damit diese Änderungen wirksam werden:
$ sudo update-initramfs -u