ubuntuusers.de

Hallo,

ich habe auch meinem Lenovo W530 hibernate nach folgender Anleitung eingerichtet:

https://rephlex.de/blog/2019/12/27/how-to-hibernate-and-resume-from-swap-file-in-ubuntu-20-04-using-full-disk-encryption/

Es funktioniert auch so in 50% der Fälle. Manchmal bleibt nach dem Aufwachen der Bildschirm schwarz und es reagiert nichts. Manchmal entstehen Grafikfehler (halbtransparentes Rechteck überlagert). Manchmal hängt gnome-shell, obwohl ich:

1

gsettings set org.gnome.desktop.interface clock-show-seconds false

gemacht habe.

Was habe ich falsch gemacht? Wie kann ich das Problem beheben?

Hallo!

Tesla42 schrieb:

Was habe ich falsch gemacht? Wie kann ich das Problem beheben?

Das kann außer dir keiner wissen. Beim überfliegen des Blog-Eintrages ist mir nur aufgefallen, dass die systemd-unit nicht komplett geändert, sondern lediglich Code hinzugefügt wird, was schonmal nicht so gut ist. In meiner (unveränderten) sind nämlich bereits Einträge im Bereich [Service] vorhanden.
Zeige mal

1

systemctl cat systemd-hibernate

Ich vermute mal ob der Schlampigkeit doppelte Einträge. Ansonsten solltest du noch journalctl nach entsprechenden Fehlschlägen filtern.

Sieht gut aus. Zeig mal noch bitte cat /proc/cmdline.
Was den bisherigen Verlauf angeht (Logdateien) mindestens noch ein „Schlaftagebuch“:

journalctl -u systemd-suspend > ~/Schlaftagebuch

Das Schlaftagebuch kannst du dann je nach Größe im Codeblock oder im Paste-Service veröffentlichen.

Funktioniert der manuelle Weg?

• Einstellungen für den Schlaf prüfen:

  grep -Ev '^$|^#' /etc/systemd/sleep.conf{,.d/*} 

  (Sollte im Standard nur eine Ausgabe haben: '[Sleep]')

• alle Dienste ausmachen, die den Schlaf unterbrechen, wie Videowiedergabe, etc. Prüfbar mit systemd-inhibit --list[1].

• manuell ausführen: systemctl hibernate -T --dry-run. Damit sollten dir Gründe angegeben werden, wieso kein suspend ausgeführt werden kann/könnte

• manuell ausführen: systemctl hibernate, falls es nicht klappt systemctl hibernate -i

Falls das manuelle funktioniert, musst du warten, bis es mal wieder nicht geht und dann entsprechend ein aktuelles „Schlaftagebuch“ erstellen. sudo solltest du für keinen der Befehle verwenden, der Hauptbenutzer sollte in allen nötigen Gruppen sein, ansonsten fragt systemd schon nach der Berechtigung oder warnt.

Falls das auch nicht funktioniert, teste zunächst, ob systemctl suspend funktioniert.

• 1: einige Einträge wie Energieverwaltung, etc sind normal. Die haken sich da ein, weil sie vor dem Schlaf noch Scripte laufen lassen

Suspend funktioniert problemlos.

1

sudo systemctl hibernate

klappt auch immer, nur halt das Aufwachen nicht zuverlässig.

1

cat /proc/cmdline

BOOT_IMAGE=/vmlinuz-5.8.0-63-generic root=UUID=4ff3d19f-455a-4485-8e44-0acfe0d6267e ro resume=UUID=4ff3d19f-455a-4485-8e44-0acfe0d6267e resume_offset=34816

1

journalctl -u systemd-suspend > ~/Schlaftagebuch

https://paste.ubuntuusers.de/424067/

1

grep -Ev '^$|^#' /etc/systemd/sleep.conf{,.d/*} 

/etc/systemd/sleep.conf:[Sleep]
grep: /etc/systemd/sleep.conf.d/*: No such file or directory

1

systemd-inhibit --list

WHO                          UID  USER   PID  COMM            WHAT                                                     WHY                                                       MODE 
ModemManager                 0    root   1151 ModemManager    sleep                                                    ModemManager needs to reset devices                       delay
NetworkManager               0    root   955  NetworkManager  sleep                                                    NetworkManager needs to turn off networks                 delay
UPower                       0    root   1361 upowerd         sleep                                                    Pause device polling                                      delay
Unattended Upgrades Shutdown 0    root   1205 unattended-upgr shutdown                                                 Stop ongoing upgrades or perform upgrades before shutdown delay
GNOME Shell                  1000 stefan 3939 gnome-shell     sleep                                                    GNOME needs to lock the screen                            delay
stefan                       1000 stefan 4078 gsd-media-keys  handle-power-key:handle-suspend-key:handle-hibernate-key GNOME handling keypresses                                 block
stefan                       1000 stefan 4078 gsd-media-keys  sleep                                                    GNOME handling keypresses                                 delay
stefan                       1000 stefan 4081 gsd-power       sleep                                                    GNOME needs to lock the screen                            delay

1

systemctl hibernate -T --dry-run

(Befehl läuft ohne Ausgabe durch.)

Für systemctl hibernate brauche ich, glaube ich, sudo.

Ich folge dieser diskussion mit spannung.

Hibernate mit swapfile habe ich nie zuverlässig zum laufen gebracht. Mit swap partition aber immer.

Tesla42 schrieb:

Für systemctl hibernate brauche ich, glaube ich, sudo.

Dann sollte aber dann ein Popup kommen, welches nach der Berechtigung verlangt. Zumindest tut es das in meiner Ubuntu-VM. Dessen Gruppen sind: uid=1001(gnom) gid=1001(gnom) Gruppen=1001(gnom),27(sudo). Dort funktioniert hibernate auch direkt.

Nativ kann ich das nicht testen, da meine swap minimal ist, da wird natürlich hibernate nicht unterstützt. Zumindest funktioniert dein suspend tadellos, daher können wir inhibit&Co streichen.
Also mal bitte ein Schlaftagebuch vom hibernate erstellen. Falls du wirklich root-Rechte brauchst, kannst du das aus einer root-shell aufrufen (sudo -i).

Nachtrag: Falls es keine relevanten Einträge von vorher gibt, bitte nach dem hibernate Befehl und Neustart nochmal aufrufen. Ich vermute mal, dass das Dateisystem dann durch die swapfile noch nicht im Zugriff ist, wenn es gebraucht wird. Dem widerspricht aber, dass es ab und an klappt.

Es funktionierte jetzt mehrere Tage problemlos. Ich haber

1

systemctl hibernate 

ohne sudo gemacht. Es kam immer das Fenster mit sudo-Passwort-Abfrage.

Gerade eben hat es nicht mehr funktioniert. Nach dem Resume blieb der Bildschirm schwarz. Alt-Druck-RISUB wurde zum Neustarten verwendet. Danach muss ich mehrmal mit dieser Methode Neustarten, weil das System immer zwischendurch einfror: einmal scharzer Bildschirm mit Textcursor oben links, einmal bei der Benutzerauswahl.

ich habe das mit journalctl -u hibernate erstellt:

https://paste.ubuntuusers.de/424068/

Das sieht an sich gut aus. An der Stelle weiß ich allerdings auch nicht genau weiter, ich würde vermuten, dass einer der relevanten Units ein After=systemd-sleep fehlt, oder aber eine gestartet wird, die bei einem „unglücklichen“ Aufwachen die Reihenfolge durcheinander bringt, der Grafiktreiber einen Fehler hat oder eine sonstige Anwendung, die noch aktiv war.
Das dürfte auch sehr schwer zu debuggen sein, weil es (noch) nicht zuverlässig reproduzierbar ist.

Du könntest bspw. mal gucken, ob Anwendungen mit Speicherzugriffsfehlern „sterben“ und ob die Zeitpunkte zum Nicht-Richtig-Aufwachen passen:

journalctl -g segfault | grep -Ev Reboot

Ebenso könnte sich in /var/crash was interessantes finden.

Dann könntest du folgendes Testen:

• Ist auf dem Rechner als aktuellste UEFI installiert?

• Angeschlossene USB-Geräte, SD-Karten, Headset, Bluetooth-Kram, etc. entfernen

• login ohne grafische Oberfläche (Displaymanager deaktivieren), damit Hibernate und wakeup ausprobieren

Wie gesagt, schwierig wird es, wenn es keinen Anhaltspunkt gibt und das System in den allermeisten Fällen reagiert. Hast du denn REISUB reaktiviert? Wenn ja, kannst du nach R auf eine andere virtuelle Konsole wechseln? Eventuell könnte auch ein crashdump helfen. ⇨ Magic SysRQ

Um Anhaltspunkte zu generieren, könntest bspw. mitloggen, welche Prozesse zum Zeitpunkt des Hibernate laufen und das beim nächsten hängenbleiben gegenprüfen.