Problème hibernation par bouton extinction PC

Support Debian
#1

Bonjour à tous,

Alors voilà je rencontre un problème avec la mise en hibernation que j’essaie de résoudre en vain depuis maintenant 2 jours :smiley:

Tout d’abord je suis sous Debian Sid, pm-utils et uswsusp sont installés (quoique apparement selon le wiki uswsusp serait superflu à partir de Debian Jessie), et donc j’arrive à passer en hibernation sans problème lorsque je rentre dans un terminal en tant que root les commandes s2disk ou pm-hibernate.

Par contre, j’ai configuré le bouton marche/arrêt du PC portable pour passer en hibernation, et là ça ne marche pas… Le pc s’éteint bien comme s’il était passé en hibernation, cependant au redémarrage il se comporte effectivement comme si j’avais redémarré et non pas hiberné… Donc nouvelle session et bien entendu non pas la sauvegarde de la session censée avoir été hibernée…
Alors je ne sais pas ce que j’ai loupé au passage, mais j’ai pratiquement esssayé toutes les solutions proposées que j’ai pu trouver sur le net dans les différents sujets précédents.

Une idée?

#2

Bon apparemment j’ai trouvé une solution, toutefois je ne sais pas si elle devrait en principe être native sur Debian mais non-fonctionnelle d’origine chez moi, ou bien c’est comme ça chez tout le monde.
Donc pour résumer, en ligne de commande en tant que root, pm-hibernate et s2disk fonctionnaient parfaitement, mais pas en appuyant sur le bouton marche/arrêt du pc parametré dans Gnome-Tweak-Tool pour passer en hibernation, ou bien le bouton hibernation installé à l’aide de l’extension.
Pourtant sur le Wiki Debian il est mentionné que l’hibernation devrait fonctionner “out-of-the-box”, même sans uswsusp :
https://wiki.debian.org/Hibernation

Pour faire fonctionner ceci, j’ai donc trouvé un tuto sur ArchWiki que j’ai adapté à Debian :
https://wiki.archlinux.org/index.php/Uswsusp#With_systemd

Je soupçonnais que le problème provenait de systemd, étant donné qu’en ligne de commande en tant que root ça fonctionnait (mais ça suppose un appel direct des commandes pm-hibernate et uswsusp), alors qu’en passant par le bouton cette fonction devait faire appel à d’autres commandes du système qui devraient aller chercher pm-hibernate ou uswsusp…

Donc si vous rencontrez le même problème que moi, vérifiez que le fichier suivant est présent /etc/systemd/system/systemd-hibernate.service
Si comme chez moi il n’est pas présent, alors il va falloir passer en root et le copier à partir du répertoire /lib… et NON PAS /usr/lib/… comme dans le tuto de ArchWiki (les chemins ne sont pas tout à fait les même):

Puis, soit vous vous placez dans le dossier dans lequel vous avez copié le fichier, soit vous l’ouvrez avec votre éditeur de texte favori :

root@nom_machine:~$ cd /etc/systemd/system/ root@nom_machine:~$ gedit systemd-hibernate.service
ou par exemple :

Et il faut modifier la dernière ligne de manière à ce qu’elle ressemble de ceci :

[code]/etc/systemd/system/systemd-hibernate.service

…
ExecStart=/usr/lib/systemd/systemd-sleep hibernate[/code]
à celà

[code]/etc/systemd/system/systemd-hibernate.service

…
ExecStart=/bin/sh -c ‘s2disk && run-parts --regex .* -a post /lib/systemd/system-sleep’[/code]
Enregistrez et fermez.

Et voilà en principe après ça vos paramètres système concernant l’hibernation devraient fonctionner (que ce soit par bouton marche/arrêt, rabattage de l’écran, …).
Pour activer l’hibernation hybride, procédez de la même manière avec le fichier systemd-hybrid-sleep.service

#3

Néanmoins, malgré que ça fonctionne, ça reste pour moi un workaround, donc si vous pouvez comparer avec vos installations et commenter cette publication ça m’aiderait à comprendre et en savoir un peu plus pourquoi il a fallu passer par là pour faire fonctionner l’hibernation alors qu’elle est apparemment censée fonctionner out-of-the-box (à partir de Jessie…).
La question est de savoir pourquoi les fichiers *.service ne sont pas en natif copiés dans le répertoire /etc/systemd/system et qu’est ce qui bloque le processus natif de mise en hibernation sans passer par la ligne de commande en tant que root.

#4

Salut
A priori ça passe par acpi

ubuntu-desktop:/sys/power$ ls disk pm_freeze_timeout pm_trace resume wake_unlock image_size pm_print_times pm_trace_dev_match state wakeup_count pm_async pm_test reserved_size wake_lock @ubuntu-desktop:/sys/power$ cat resume 8:5 @ubuntu-desktop:/sys/power$ cat state freeze mem disk
acpi.sourceforge.net/documentation/sleep.html
Cf:
bouton-power-hibernation-menu-utilisateur-sur-gnome-t50609.html

sortie-de-veille-intempestive-t51192.html

#5

Salut grandtoubab,

J’avais déjà consulté ces liens que j’avais trouvé via internet, mais ça reste vague d’autant que la personne en question était sous gnome 3.4.
C’est bien systemd qui gère les requetes d’extinction, mise en veille, hibernation et autres au moyen de fichier *.target, *.service, … Mais ce que je cherche à comprendre maintenant c’est pourquoi ça n’a pas tout simplement marché en natif, et il m’a donc fallu passer par “cette bidouille” pour y arriver…

#6

[quote=“GOGI”]Salut grandtoubab,

J’avais déjà consulté ces liens que j’avais trouvé via internet, mais ça reste vague d’autant que la personne en question était sous gnome 3.4.
C’est bien systemd qui gère les requetes d’extinction, mise en veille, hibernation et autres au moyen de fichier *.target, *.service, … Mais ce que je cherche à comprendre maintenant c’est pourquoi ça n’a pas tout simplement marché en natif, et il m’a donc fallu passer par “cette bidouille” pour y arriver…[/quote]
A priori ça passe par acpi

ubuntu-desktop:/sys/power$ ls disk pm_freeze_timeout pm_trace resume wake_unlock image_size pm_print_times pm_trace_dev_match state wakeup_count pm_async pm_test reserved_size wake_lock @ubuntu-desktop:/sys/power$ cat resume 8:5 @ubuntu-desktop:/sys/power$ cat state freeze mem disk
acpi.sourceforge.net/documentation/sleep.html

help.ubuntu.com/community/Power … /Hibernate

#7

Oui ça je sais, mais ACPI agit sur un niveau différent du niveau utilisateur. ACPI interfère sur la gestion de l’énergie, mais ne passe pas de commandes, donc le problème ne situe pas à ce niveau…