Hibernation à utiliser systemctlet à faire fonctionner dans des cas difficiles
Pour moi, pm-hibernateéchoue toujours. Après quelques ajustements, j'ai pu hiberner en utilisant l'interface de systemd (init system à partir de 16.04). J'ai également réussi à le faire fonctionner le 17.04 avec un fichier d'échange. Cette étude de cas peut être utile pour les personnes ayant des problèmes.
Premier essai:
sudo systemctl hibernate
En cas d'échec, commencez le dépannage: dans l'état de veille prolongée (HTD ou ACPI S4), l'état de l'ordinateur est écrit sur le disque, de sorte qu'aucune alimentation n'est nécessaire pour le conserver. L'état est écrit sur une partition d'échange ou dans un fichier d'échange. Remarque: si vous utilisez Btrfs, n'essayez PAS d'utiliser un fichier d'échange, car cela pourrait endommager le système de fichiers.
Votre partition d'échange ou fichier d'échange devra peut-être avoir la même taille que la RAM pour permettre l'hibernation, mais il y a de bonnes chances que vous puissiez passer en hibernation si sa taille est au moins égale à 2/5 de la taille de la RAM, selon la page du wiki Arch. , essayez d’abord d’autres étapes avant d’augmenter la taille de l’échange.
Si votre problème est que vous obtenez un démarrage en mode minimal au lieu du CV attendu, vous devez au moins probablement définir un paramètre de démarrage pour rechercher l'image du disque.
Trouvez votre partition d'échange:
grep swap /etc/fstab
pour moi cela retourne (sortie partielle)
# swap was on /dev/mmcblk0p3 during installation
où /dev/mmcblk0p3est la partition à spécifier
Ajouter un paramètre de démarrage:
sudoedit /etc/default/grub
À la ligne qui commence, GRUB_CMDLINE_LINUX_DEFAULTajoutez resume=/dev/YourSwapPartitiondes guillemets à la section (remplacez-la par la partition que vous avez identifiée précédemment). En utilisant mon exemple:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=/dev/mmcblk0p3"
Chaque fois que vous modifiez ce fichier, vous devez l'exécuter sudo update-grubou les modifications n'auront aucun effet.
Maintenant, vous devez redémarrer. Ensuite, vous pouvez essayer de hiberner, en lançant la commande:
sudo systemctl hibernate
Pour reprendre, appuyez sur le bouton d'alimentation et le système va démarrer.
Si vous avez toujours des problèmes, démarrez le débogage.
J'inclus mon cas ci-dessous à titre d'exemple, mais des informations détaillées sur le débogage des états S se trouvent dans ce blog et celui-ci .
Définissez quelques paramètres de démarrage supplémentaires pour capturer plus d'informations. Supprimez quietet splashajoutez initcall_debug, no_console_suspendce qui entraînera l’impression des appels système init sur la console afin que vous puissiez voir ce qui ne va pas. J'ai mis ceci:
GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/mmcblk0p3 no_console_suspend initcall_debug"
Ce qui m'a aidé à voir ce qui n'allait pas sur le résumé de l'hibernation.
Dans mon cas, après la reprise, j’ai perdu le WiFi, et le noyau était clairement bouleversé, car la plupart des commandes (lire /sys, recharger des modules ou n’importe quelle systemctlcommande) ne fonctionneraient pas - le processus semblerait démarrer et s’arrêter juste retourné à la normale après le redémarrage bien sûr). En regardant le système s’arrêter très lentement et en lisant tous les messages de débogage, j’ai remarqué qu’il y avait beaucoup de problèmes avec "brcm". J’imaginais donc que le module de pilote sans fil Broadcom était à blâmer. Bien sûr, j'ai ajusté ma procédure d'hibernation pour décharger le module en premier:
sudo modprobe -r brcmfmac
sudo systemctl hibernate
en reprise je réinsère le module
sudo modprobe brcmfmac
Et tout a fonctionné parfaitement. Je dois également lister le btsdiomodule qui semble incompatible avecbrcmfmac
Mise à jour: mise en veille prolongée à l'aide d'un fichier d'échange le 17.04.
Encore une fois, avec l'aide de la page Arch wiki et quelques modifications supplémentaires, j'ai réussi à faire passer l'hibernation en mode 17.04 avec un fichier d'échange. Cela nécessitait un paramètre d’amorçage supplémentaire, resume_offset=noù n est le premier nombre situé en dessous physical_offsetde la sortie de sudo filefrag -v /swapfile:
$ sudo filefrag -v /swapfile
Filesystem type is: ef53
File size of /swapfile is 1425873920 (348114 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 32767: 34816.. 67583: 32768:
1: 32768.. 63487: 67584.. 98303: 30720:
....
Par conséquent, le paramètre de démarrage supplémentaire dans mon cas est resume_offset=34816. Vous devez toujours définir un paramètre de démarrage pour que la partition puisse reprendre. Ce sera la partition racine (ou la partition sur laquelle se trouve votre fichier d'échange). Mes paramètres sont maintenant:
GRUB_CMDLINE_LINUX_DEFAULT="no_console_suspend initcall_debug resume=/dev/mmcblk1p2 resume_offset=34816"
Où se /dev/mmcblk1p2trouve ma partition racine (la vôtre sera plus ou moins similaire /dev/sda2).
Pendant la reprise, j'ai vu le chargement de l'image réussir, mais dans mon cas (juste un exemple - YMMVAPD), quelques pilotes supplémentaires ( i2c_designware) ont jeté quelques erreurs et j'ai obtenu un gel complet du CV. Le mode veille prolongée fonctionne si je décharge ces modules en plus brcmfmac, mais le système devient rapidement inutilisable sans ces modules. J'ai donc fait une sorte de script pour décharger les modules buggy et les réinsérer immédiatement sur CV:
# remove buggy modules
modprobe -r brcmfmac i2c_designware_platform i2c_designware_core &&
# hibernate
echo disk > /sys/power/state
# reinsert
modprobe i2c_designware_core i2c_designware_platform brcmfmac
Quand je veux hiberner, je cours sudo bash script. Cela fonctionne très bien.
TL; DR
Utilisez systemd, définissez un paramètre d’amorçage pour le reprendre à partir du swap, identifiez les pilotes défectueux et déchargez-les avant de mettre en veille prolongée. Si le système ne peut pas fonctionner longtemps sans ces modules ou si vous devez en décharger plusieurs, il peut être plus facile d'utiliser un simple script pour activer le mode veille prolongée.