ubuntuusers.de

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!

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.

Das tote TuxOnIce ist aber irgendwie Bestandteil der hier beschriebenen Methode:

$ sudo hibernate
hibernate:Warning: Tuxonice binary signature file not found.

das dachte ich mir auch schon... 😉
aber siehe meinen vorigen absatz; eine diskussion darüber ist dann quasi hinfällig.

DJCrashdummy schrieb:

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.

Viel passiert ist ja noch nicht – genauer – gar nichts 😬

Bin schon gespannt wann ich meinen PC mit Bordmittel in den Ruhezustand schicken kann 😉 Biete mich zum Testen an 😊

Kellerkind_2009 schrieb:

Viel passiert ist ja noch nicht – genauer – gar nichts 😬

ich bearbeite doch "offline"... weil mir ist schon zu oft passiert, dass der browser dann in die knie ging oder der strom ausfiel und die arbeit von ein paar tagen weg war! 😠

PROBLEM:
der befehl zum ermitteln des offsets bei swapfiles (swap-offset) ist im paket uswsusp enthalten, welches bekanntlich nach 20.04 aus den paketquellen geflogen ist!

dass die überarbeitung sinnvoll & nachhaltig ist, sollte auch da eine lösung gefunden werden... ich wäre sehr dankbar wenn jemand checken kann, ob/wie man den befehl auf systemen >20.04 bekommt; oder für generelle alternativen zu

sudo swap-offset /swapfile

bin ich natürlich genau so offen bzw. wären die IMHO noch besser.

Danke!

PS: auch irgendwie "lustig"... der befehl swap-offset wird im artikel "zur vorbereitung" noch vor der installation verwendet. 😉

Nehme

sudo filefrag -v /swapfile | head

Gruß Stephan

Nachtrag

stephan@stephan-desktop:~$ sudo filefrag -v /swapfile | head
Filesystem type is: ef53
File size of /swapfile is 1625108480 (396755 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   63487:      34816..     98303:  63488:            
   1:    63488..  126975:     100352..    163839:  63488:      98304:
   2:   126976..  190463:     165888..    229375:  63488:     163840:
   3:   190464..  253951:     231424..    294911:  63488:     229376:
   4:   253952..  396754:     296960..    439762: 142803:     294912: last,eof
/swapfile: 5 extents found
stephan@stephan-desktop:~$ 

Kellerkind_2009 schrieb:

Nehme

sudo filefrag -v /swapfile | head

Gruß Stephan

danke für die fixe hilfe! - aber bist du dir sicher, dass du mit sudo swap-offset /swapfile das gleiche ergebnis bekommst?!?

weil ich würde eher folgendes nehmen...

stephan@stephan-desktop:~$ sudo filefrag -v /swapfile | head
Filesystem type is: ef53
File size of /swapfile is 1625108480 (396755 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   63487:      34816..     98303:  63488:            
   1:    63488..  126975:     100352..    163839:  63488:      98304:
   2:   126976..  190463:     165888..    229375:  63488:     163840:
   3:   190464..  253951:     231424..    294911:  63488:     229376:
   4:   253952..  396754:     296960..    439762: 142803:     294912: last,eof
/swapfile: 5 extents found

...bzw. in einer zeile, um eine nicht so "verwirrende" ausgabe - für den artikel - zu bekommen:

sudo filefrag -v /swapfile | awk 'NR==4 { gsub(/\./,"") ; print $4 ; }'

es geht ja so weit ich verstanden habe, um den physischen offset auf dem datenträger bei welchem die swapfile beginnt und "was somit beim aufwachen zu lesen ist", oder...?

bitte um recheck, bestätigung, korrektur, verbesserung, aufklärung, erklärung und/oder erleuchtung. 😉 DANKE nochmal!

DJCrashdummy schrieb:

...bzw. in einer zeile, um eine nicht so "verwirrende" ausgabe - für den artikel - zu bekommen:

sudo filefrag -v /swapfile | awk 'NR==4 { gsub(/\./,"") ; print $4 ; }'

Hast Recht,ist richtig so (physical_offset 1ste Spalte) (Arch sieht es genauso 😉 )

es geht ja so weit ich verstanden habe, um den physischen offset auf dem datenträger bei welchem die swapfile beginnt und "was somit beim aufwachen zu lesen ist", oder...?

So ist auch mein Wissensstand.

Gruß Stephan

danke Kellerkind_2009 für die schnelle rückmeldung, die idee, den support und die bestätigung.

Habe den ersten erfolgreichen Hibernate unter 21.10 mit systemd hinbekommen 😬

Einstellungen

/etc/default/grub ## "quiet resume=swapfile"
/etc/initramfs-tools/conf.d/resume ## RESUME=swapfile resume_offset=34816

Er meldet zwar beim beenden immer noch die Readon Fehler – aber es Funktioniert!

stephan@stephan-desktop:~$ uname -a
Linux stephan-desktop 5.13.0-19-generic #19-Ubuntu SMP Thu Oct 7 21:58:00 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
stephan@stephan-desktop:~$ lsb_release -a
LSB Version:	core-11.1.0ubuntu3-noarch:printing-11.1.0ubuntu3-noarch:security-11.1.0ubuntu3-noarch
Distributor ID:	Ubuntu
Description:	Ubuntu 21.10
Release:	21.10
Codename:	impish
stephan@stephan-desktop:~$ lspci -nnk | grep -i "VGA\|'Kern'\|3D\|Display" -A4
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RV710 [Radeon HD 4350/4550] [1002:954f]
	Subsystem: PC Partner Limited / Sapphire Technology RV710 [Radeon HD 4350/4550] [174b:0e13]
	Kernel driver in use: radeon
	Kernel modules: radeon
01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] RV710/730 HDMI Audio [Radeon HD 4000 series] [1002:aa38]
stephan@stephan-desktop:~$ 

Nachtrag

Abfragen sehen dann wie folgt aus

stephan@stephan-desktop:~$ cat /sys/power/resume
8:33
stephan@stephan-desktop:~$ cat /sys/power/resume_offset
34816
stephan@stephan-desktop:~$ 

stephan@stephan-desktop:~$ sudo dmesg | grep hiber
[    0.064875] PM: hibernation: Registered nosave memory: [mem 0x00000000-0x00000fff]
[    0.064877] PM: hibernation: Registered nosave memory: [mem 0x0009f000-0x0009ffff]
[    0.064878] PM: hibernation: Registered nosave memory: [mem 0x000a0000-0x000e3fff]
[    0.064879] PM: hibernation: Registered nosave memory: [mem 0x000e4000-0x000fffff]
[    0.064881] PM: hibernation: Registered nosave memory: [mem 0xcfe80000-0xcfe97fff]
[    0.064882] PM: hibernation: Registered nosave memory: [mem 0xcfe98000-0xcfebffff]
[    0.064883] PM: hibernation: Registered nosave memory: [mem 0xcfec0000-0xcfefffff]
[    0.064884] PM: hibernation: Registered nosave memory: [mem 0xcff00000-0xffdfffff]
[    0.064885] PM: hibernation: Registered nosave memory: [mem 0xffe00000-0xffffffff]
[  656.642025] PM: hibernation: hibernation entry
[  656.890884] PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff]
[  656.890887] PM: hibernation: Marking nosave pages: [mem 0x0009f000-0x000fffff]
[  656.890890] PM: hibernation: Marking nosave pages: [mem 0xcfe80000-0xffffffff]
[  656.891613] PM: hibernation: Basic memory bitmaps created
[  656.891614] PM: hibernation: Preallocating image memory
[  657.924364] PM: hibernation: Allocated 543662 pages for snapshot
[  657.924370] PM: hibernation: Allocated 2174648 kbytes in 1.03 seconds (2111.30 MB/s)
[  658.417937] PM: hibernation: Creating image:
[  658.871482] PM: hibernation: Need to copy 566003 pages
[  658.871486] PM: hibernation: Normal pages needed: 566003 + 1024, available pages: 3623431
[  660.415018] PM: hibernation: Basic memory bitmaps freed
[  660.418503] PM: hibernation: hibernation exit
stephan@stephan-desktop:~$ 

DJCrashdummy schrieb:

das was mir zu dem thema auf die schnelle einfällt, ist nur via GRUB...

1 2	GRUB_SAVEDEFAULT=true GRUB_DEFAULT=saved

...aber das ist - so viel ich weiß - eh die default einstellung. somit sehe ich keinen grund das extra aufzunehmen und den user auch noch damit zu beschäftigen.

Nein, das ist nicht so. Die Standardeinstellung ist:

1

GRUB_DEFAULT=0

• Wie erzwingt man, dass nach dem Aufwachen erst mal der Anmeldeschirm mit Passwortabfrage kommt, anstatt das jeder gleich freie Bahn hat. Vermutlich gibt es dafür irgendwo einen Schalter.

ich bin mir nicht sicher, ob ich verstehe was du meinst... von welchem passwort und "anmeldebildschirm" sprichst du?

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

UlfZibis schrieb:

[...] Die Standardeinstellung ist:

1	GRUB_DEFAULT=0

stimmt! bin da in den letzten tagen auch drüber gestolpert... dann werde ich meine idee vielleicht doch in den artikel aufnehmen.

• Wie erzwingt man, dass nach dem Aufwachen erst mal der Anmeldeschirm mit Passwortabfrage kommt, anstatt das jeder gleich freie Bahn hat. Vermutlich gibt es dafür irgendwo einen Schalter.

ich bin mir nicht sicher, ob ich verstehe was du meinst... von welchem passwort und "anmeldebildschirm" sprichst du?

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 ist - so viel ich glaube zu wissen - auch ein unterschied zu sleep.

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"

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)...?! ❓
ich habe zb. auch andere anleitungen im internet ohne dieses vorgehen gefunden und beim test mit einem jungfräulichen 20.04 scheint es auch ohne dieser file zu funktionieren.

ich habe die vermutung, dass das vielleicht von hibernate oder uswsusp benötigt wird/wurde... aber bei manchen anleitungen ist das vogehen wieder zu ev. fehlerbehebung angeführt. ganz andere meinen, dass zur fehlerbehebung die zeile/file gelöscht oder zumindest zu RESUME=none geändert werden soll. und die nächsten meinen, dass es mit RESUME in großbuchstaben sowieso nicht funktioniert! 😳
→ also nach der recherche bin ich eigentlich noch unsicherer als davor! falls jemand etwas mehr einblick in die materie hat, bitte ich um aufklärug. danke!

DJCrashdummy schrieb:

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)...?! ❓

Damit das initrd.img des Kernel gebaut wird.

• sudo update-initramfs -u -k all ## für alle Installierten Kernel

• sudo update-initramfs -u -k 5.4.0-84-generic ## mit nur dem angegebenen Kernel

• sudo update-initramfs -u ## mit dem zur Zeit Verwendeten Kernel

ich habe zb. auch andere anleitungen im internet ohne dieses vorgehen gefunden und beim test mit einem jungfräulichen 20.04 scheint auch ohne dieser file alles zu funktionieren.

Das ist einer der Gründe wie komplex Hibernate ist.

ich habe die vermutung, dass das veilleicht von hibernate oder uswsusp benötigt wird/wurde... aber bei manchen anleitungen ist das vogehen wieder zu ev. fehlerbehebung angeführt. und ganz andere meinen, dass es mit RESUME in großbuchstaben sowieso nicht funktioniert!

Laut man initramfs-tools

Der Resume-Hook versucht, die Resume-Partition automatisch zu erkennen und verwendet die erste Swap-Partition als gültige Vermutung. Es ist möglich die Variable RESUME in /etc/initramfs-tools/conf.d/resume zu setzen. Die Boot-Variable noresume hat Vorrang vor ihr.

Gruß Stephan

wozu danach update-initramfs benötigt wird, ist mir klar... hier wird auch sehr richtig sudo update-initramfs -u -k all verwendet und nicht nur - wie leider viel zu oft - fälschlicher weise sudo update-initramfs -u.

meine verwirrung bezieht sich darauf wieso und von welchen prozessen /etc/initramfs-tools/conf.d/resume benötigt wird, warum es ohne auch auch zu funktionieren scheint und sich die ev. fehlebehebungen widersprechen.

→ falls da keine klare aussage oder vorgehensweise herausgearbeitet werden kann, sollte ich es ev. weglassen und dann als erste mögliche fehlerbehebung anführen? - dennoch würde ich gerne eine minimale erklärung dazu schreiben!

Kellerkind_2009 schrieb:

Laut man initramfs-tools

Der Resume-Hook versucht, die Resume-Partition automatisch zu erkennen und verwendet die erste Swap-Partition als gültige Vermutung. Es ist möglich die Variable RESUME in /etc/initramfs-tools/conf.d/resume zu setzen. Die Boot-Variable noresume hat Vorrang vor ihr.

ja, die manpage hab ich natürlich auch gelesen. weiter unten wird dann die resume-variable in kleinbuchstaben verwendet. 😐

Da kann ich nichts genaues zu sagen.Es ist auf jeden Fall deshalb schon Unterschiedlich,weil es eine Swap-Partition sowie ein Swapfile (neuere) gibt.

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

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

Auf meinen Laptop mit Nvidia Grafik sieht die Welt wieder ganz anders aus!Dort habe ich es ohne hibernate und uswsusp noch nicht ans Laufen gebracht (swapfile) 😕