18.04 mise en veille prolongée avec UEFI et démarrage sécurisé activé
"Sudo systemctl start hibernate.target" a bien fonctionné avec 16.04 sur un Acer B117 utilisant un démarrage hérité; La mise à jour vers 18.04 m'a obligé à utiliser UEFI et (exigence Acer) le démarrage sécurisé activé. La suspension fonctionne toujours, mais j'ai besoin de la mise en veille prolongée.
La partition de swap est active et équivaut à RAM taille + 2 Go;
GRUB_CMDLINE_LINUX_DEFAULT = "reprise d'éclaboussure silencieuse = UUID = myswapuuid"
journalctl -xe a révélé l'échec de l'accès à/sys/power/disk
cat/sys/power/disk: [désactivé]
cat/sys/power/state: gel mem
Aucune suggestion?
J'ai le même problème et, malheureusement, c'est impossible avec le noyau Ubuntu officiel depuis la version 4.13 en raison du patchset de verrouillage du noyau (efi-lockdown). La justification est:
Il n'existe actuellement aucun moyen de vérifier l'image de reprise lors du retour de la mise en veille prolongée. Cela pourrait compromettre le modèle de confiance des modules signés, donc jusqu'à ce que nous puissions travailler avec des images d'hibernation signées, nous le désactivons lorsque le noyau est verrouillé.
Engagement Bionic associé que vous pouvez voir ici .
C'est une décision controversée et Linus a refusé de fusionner ces changements au noyau linux.
Un peu plus de détails que vous pouvez trouver est l'article Verrouillage du noyau en 4.17? et ses commentaires.
Donc, pendant que nous attendons un logiciel magique, qui fonctionnera avec des images d'hibernation signées, nous ne pouvons utiliser qu'un autre noyau ou désactiver le démarrage sécurisé .
P.S. Je serai heureux de voter une autre réponse si quelqu'un a résolu ce problème.
j'espère que cela aidera quelqu'un, mais je lance popos/ubuntu 19.04. Dans ma configuration, j'ai pu mettre en veille prolongée à l'aide de s2disk ou pm-hibernate, mais la reprise a échoué. Pour résoudre ce problème, car mon système est démarré en utilisant UEFI au lieu de grub. Je viens de réinstaller le chargeur de démarrage. Pour vérifier si vous exécutez UEFI, utilisez les éléments suivants:
[ -d /sys/firmware/efi ] && echo "Installed in UEFI mode" || echo "Installed in Legacy mode"
si en mode UEFI, j'ai suivi ce guide pour réinstaller le chargeur de démarrage, cela varie si vous utilisez un disque nvme ou un disque sata: https://support.system76.com/articles/bootloader/
La clé est d'exécuter cette commande:
Sudo update-initramfs -c -k all
assurez-vous que dans vos options kernalboot, vous spécifiez la partition ou l'UUID d'où reprendre, par exemple quelque chose comme ceci:
resume = UUID = ed8347ed-2eb4-40bc-bc77-cc53b987ed88
Vous pouvez ajouter ceci soit: 1) Sudo kernel-stub -a "resume = UUID = ..." 2) éditez le fichier /etc/initramfs-tools/conf.d/resume et ajoutez: resume = UUID = ed8347ed- 2eb4-40bc-bc77-cc53b987ed88
vérifier votre /var/log/syslog fichier pour quelque chose comme ceci:
Aug 4 22:26:42 pop-os /usr/bin/kernelstub[19639]: kernelstub : DEBUG kopts: root=UUID=b37019a8-91f5-445f-94c1-7359a49ed5df ro quiet loglevel=0 systemd .show_status=false resume=UUID=ed8347ed-2eb4-40bc-bc77-cc53b987ed88
Si le CV est manquant ou erroné, vous devrez à nouveau mettre à jour votre boot kernal.