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 d'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 à une taille de RAM + 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 officiel Ubuntu 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 hibernées signées, nous le désactivons lorsque le noyau est verrouillé.

Engagement Bionic associé que vous pouvez voir ici .

Il s'agit d'une décision controversée et Linus a refusé de fusionner ces modifications au noyau Linux.

Un peu plus de détails que vous pouvez trouver est l'article Verrouillage du noyau dans 4.17? et ses commentaires.

Donc, en attendant 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é .

PS 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 de 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érifiez votre /var/log/syslogfichier 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.