ubuntuusers.de

Kellerkind_2009 schrieb:

Bei der Abfrage von

findmnt -no SOURCE,UUID -T /swapfile 

wird ja die uuid ermittelt,die dann in die grub,sowie in die resume eingetragen werden soll.Wie ich schrieb Funktioniert es bei mir so nicht.

Funktion bei mir nun Zuverlässig nur mit diesen Einträgen

ja, ich verwende auch lieber den partitionspfad, anstatt die UUID... aber ich glaube (heißt nix wissen) mit der UUID ist man üblicher weise auf der sichereren seite.
→ das ist doch eh irgendwo als experten-info drinnen; wenn nicht kommt's bei mir hinein.

Ohne erzeugte /etc/initramfs-tools/conf.d/resume Funktioniert es bei mir ebenfalls nicht.

hmm... das ist interessant! wenn du die einträge in initramfs brauchst, funktioniert es dann bei dir auch ohne den änderungen an grub?!?
→ diese vermutung bzw. frage basiert auf meiner weiteren recherche...

laut meiner weiteren recherche sollte angeblich der eintrag in /etc/default/grub oder /etc/initramfs-tools/conf.d/resume ausreichend sein (was IMHO sinn ergibt), wobei der kernel-parameter in grub den vorrang hat.
→ ich bitte das mit vorsicht zu genießen, weil es zu dem thema leider kaum eindeutig aktuelle aussagen von zweifelsfrei kompetenten stellen gibt.

wenn das stimmt, wäre es vielleicht anders rum einfacher (weil dann ev. ein "zurückbauen" vom ersten versuch nicht unbedingt notwendig ist):

1. generell nur die initramfs-variante vorschlagen

2. bei nicht-funktionieren, die grub-variante (dazu) probieren

3. und dann (für experten) ev. noch den rückbau der initramfs-variante vorschlagen um alle eventualitäten auzuschließen...

4. danach (auf systemen <=20.04) den versuch von uswsusp und/oder hibernate vorschlagen

5. und zum schluss natürlich die spezifischen fehlerbehebungen

PS: außer es kommt ein eindeutiger "gegenbeweis", bleibe ich bei "resume" in grub und "RESUME" in initramfs.

DJCrashdummy schrieb:

Ich meine die Anzeige, die nach Bereitschaft, Abmelden oder dem Rechnerstart kommt, wo man das Ubuntu-Benutzerkennwort eingibt.

also grundsätzlich solltest du sowieso nach deinem passwort für die FDE gefragt werden.

Das habe ich mir eben auch gedacht, doch bei mir war das eben nicht so. Deshalb meine Anfrage, im Artikel darauf zu achten. Wofür steht "FDE"?

das ist - so viel ich glaube zu wissen - auch ein unterschied zu sleep.

Damit meinst Du wohl Bereitschaft.

aber wenn du auch nach dem user-passwort gefragt werden willst - weil du ev. ein mehrbenutzer-system hast - ist das definiv einstellungssache der DE. ...und möglich, dass es nicht bei allen einen schalter im GUI dafür gibt.
ich weiß nicht, ob das zb. bei (Ubuntu) MATE standard ist, aber hier der entsprechende abschnitt aus meinem einstellungs-script welches ich über jeden meiner PCs drüber laufen lasse:

gsettings set org.mate.power-manager lock-hibernate "true"
gsettings set org.mate.power-manager lock-suspend "true"
gsettings set org.mate.power-manager lock-blank-screen "true"
gsettings set org.mate.power-manager lock-use-screensaver "true"
gsettings set org.mate.power-manager lock-keyring-hibernate "true"
gsettings set org.mate.power-manager lock-keyring-suspend "true"

Das ist ja schon mal ein Ansatz. Mal gucken, ob es für LightDM und GDM ähnliches gibt.

DJCrashdummy schrieb:

noch eine letzte unsicherheit bzw. frage:

ich bin mir nicht ganz sicher, wieso /etc/initramfs-tools/conf.d/resume bearbeitet bzw. erstellt werden muss (mit anschließendem sudo update-initramfs -u -k all)...?! ❓
.....

Gut dass Du diese Fragen mal in den Raum wirfst. Ich hatte mich das irgendwie nicht getraut.

DJCrashdummy schrieb:

UlfZibis schrieb:

[...] Auf meinem aktuell damit konfrontierten Rechner funktioniert die hibernate+uswsusp-Methode nur unter 20.04, nicht aber unter 18.04. Siehe 9277761 und auch 9277769

ja, unter 18.04 gibt es beim Ruhezustand noch einige bugs mehr als in 20.04... da funktioniert vieles um einiges besser!

Ich hab' mein 32-Bit 18.04 nun dem 20.04 etwas angenähert, und siehe da, jetzt funktioniert der Ruhezustand nun doch.

Jetzt ist nur noch unklar, warum der Passwortschutz nach dem Aufwachen umgangen wird, und ob diese Menü-Bedienung, die ja für die Kernel-Methode gedacht ist, auch für die Userspace-Methode geeignet ist.

Zumindest sollte hier ein Verweis auf das Kapitel pm-hibernate erfolgen.

ich würde mich im artikel auf systemctl hibernate & pm-hibernate fokussieren (weil immer verfügbar) und hibernate & uswsusp (ev. bei der problembehebung?) "erwähnen", weil sie nach 20.04 via paketquellen nicht mehr verfügbar sind.

Interessanterweise ist das, was noch längere Gültigkeit hat, schon im Archiv. Wo systemctl hibernate hier im Wiki erklärt wird, finde ich gerade nicht, aber dafür entdecke ich gerade, dass es noch einen 2. uswsusp-Artikel gibt. Also das Thema Ruhezustand ist hier im Wiki ziemlich unübersichtlich verstreut. Insofern freue ich mich über die Initiative von DJCrashdummy, das alles in hiesigem Artikel mal zusammenzufassen.

Jetzt zeigt ich aber noch ein Problem. Ich kann mich erinnern, das es mal eine Einstellung gab, mit der man einstellen konnte, dass der Rechner (getrennt nach Akku- oder Netzbetrieb) Automatisch in den Ruhezustand geht, sobald der Akku zuneige geht, oder der Deckel zugeklappt wird. Weiß jemand, wie das geht?

Das sollte jedenfalls auch noch in hiesigem Artikel erklärt werden.

Hallo,

wenn jemand weiß, wie das geht → kann gerne eingetragen werden. Alternativ kannst du auch eine "ausbaufähig" Box einbauen. Die ist genau für so was da.

Bei meinem E550 mit Ubuntu 20.04 kann man das via GUI soweit ich das sehe nicht einstellen. Nur Bereitschaft geht.

Gruß, noisefloor

noisefloor schrieb:

Bei meinem E550 mit Ubuntu 20.04 kann man das via GUI soweit ich das sehe nicht einstellen. Nur Bereitschaft geht.

Unter org.gnome.settings-daemon.plugins.power gibt's da ein paar Spielereien. Ich kann's leider nicht ausprobieren, da ich kein GNOME habe. Vielleicht kannst Du es ja mal ausprobieren, und berichten.

Ich bin fertig mit der Überarbeitung und stelle die neue Fassung zur Diskussion.

Artikel ist wieder im Wiki.