Essayez de créer /etc/systemd/sleep.conf :

[Sleep]
SuspendMode=
SuspendState=mem

Et rebooter. Cela semble fonctionner pour moi, bien que je ne sois pas certain que je n'ai pas également obtenu une amélioration avec la fonction /etc/systemd/logind.conf changement que j'ai fait en premier. Dans tous les cas, aucun bruit de chaleur ou de ventilateur n'est observé lorsqu'il est suspendu avec le couvercle fermé, et il ne répond pas non plus au ping sur le wifi, ce que j'ai fait. avait que je recevais, par intermittence, auparavant.

La durée de vie de la batterie continue de diminuer pendant la suspension, probablement parce que la méthode de suspension utilisée est moins efficace que la méthode par défaut, idéale, qui ne fonctionne apparemment pas correctement, mais qui semble meilleure que le comportement par défaut.

J'ai essayé sur mon XPS 13 9370, je ne sais pas pour les modèles plus anciens, mais il est probable qu'ils soient similaires.

J'avais essayé d'installer pm-utils et en utilisant pm-suspend et ça semblait suspendre assez efficacement, donc je voulais voir si je pouvais faire systemd-suspend faire la même chose.

J'ai regardé dans les scripts en pm-utils pour comprendre ce qu'il faisait réellement, et il semble que, dans cette situation, il faisait echo -n "mem" > /sys/power/state . J'ai donc créé le /etc/systemd/sleep.conf comme indiqué ci-dessus pour le faire correspondre.

Le comportement par défaut n'est pas tout à fait clair. La page de manuel de systemd-sleep.conf dit que la distribution doit inclure /etc/systemd/sleep.conf avec les défauts compilés commentés, afin que vous puissiez voir ces informations, mais dans ubuntu ce fichier est absent. J'ai remarqué cependant que si vous cat /sys/power/state vous obtenez :

freeze mem

Donc je suis deviner que c'est ce qu'il fait par défaut. Je pense que freeze peut être acceptée, dans la mesure où elle ne lève pas d'erreur, ce qui aurait autrement amené systemd à passer à mem mais peut-être pas en réalité travail correctement, ou de manière fiable, pour des raisons complexes que nous semblons incapables de déterminer. Donc, il suffit d'envoyer mem au lieu de cela, c'est un coup de poignard plein d'espoir pour éviter cela et juste faire ce que pm-suspend fait.

Je pense que le paramètre SuspendMode est en fait superflu et ne fait rien de toute façon. Je pense que c'est parce que cat /sys/power/disk t'attrape juste :

[disabled]

Je suis un nouvel utilisateur, donc incapable de commenter avec une observation, obligé de la présenter comme une réponse comme si j'en étais super confiant ! Mais je pense que ça marche.

Les autres réponses sont excellentes, approfondies et bien documentées.

Malheureusement, ils n'ont pas fonctionné pour ma machine particulière :(

Si vous disposez d'une carte graphique nVidia, il semble qu'il existe un correctif qui fonctionne pour un bon nombre de personnes, fourni de manière utile par cascagrossa dans la réponse à cette question : Ubuntu 18.04 se bloque lors d'une reprise depuis une suspension

Il est suspecté d'être un nouveau pilote bogué et peut régler les problèmes de suspension en ajoutant nouveau.modeset=0 à Grub et a été confirmé dans les commentaires pour aider à résoudre le problème pour les autres aussi.

J'ai des graphiques Intel sur ma machine à problème et, curieusement, je n'ai eu aucun problème de suspension avec Ubuntu ou Kubuntu 18.04 sur au moins 3 autres machines (celle de mon ami et la mienne), alors pourquoi cette machine en particulier est un tel connard à ce sujet n'est pas clair.

Je recommande à toute personne rencontrant ce genre de problème de suivre les étapes suivantes pour aider à identifier le problème :

1. Avez-vous des graphiques nVidia ? Si c'est le cas, essayez le nouveau.modeset=0 Grub truc.

2. Vérifiez que la suspension fonctionne. Si vous fermez le couvercle, puis l'ouvrez plus tard et qu'il ne se réveille pas, vous pouvez avoir l'impression qu'il ne parvient pas à "reprendre".

   • Vous devriez être en mesure de sélectionner manuellement la suspension sur n'importe quel bureau mais c'est légèrement caché dans Gnome Shell -. vous pouvez soit appuyer longuement sur le bouton d'alimentation dans le menu supérieur droit de l'écran, soit cliquer sur ce bouton en maintenant la touche Alt enfoncée, soit appuyer sur la touche Super et taper 'suspend'.

   • En sélectionnant suspendre, vous pouvez vérifier que l'écran s'est éteint le le voyant d'alimentation clignote comme il se doit et vous vous attendez à ce que tout ventilateur en marche s'arrête également . Si tout cela arrive mais puis Si vous n'arrivez pas à réveiller votre machine, il semble que ce soit un problème de "reprise" plutôt qu'un problème de "suspension".

   • Mon problème est que ce n'est pas en fait et Murray, qui a posé la question originale, s'est rendu compte, lorsque collisionTwo lui a demandé de vérifier, que le problème se posait également en cas de suspension manuelle.

   • Dans mon cas (sur l'ordinateur portable à un seul problème) L'écran s'éteint mais la LED d'alimentation reste allumée et si le ventilateur fonctionne, il continue à tourner. La machine ne répond pas aux pressions sur les touches, aux mouvements ou clics du pavé tactile ou aux pressions sur le bouton d'alimentation. La seule chose que l'on puisse faire est de l'éteindre.

   • J'ai essayé d'écouter de la musique tout en mettant l'ordinateur en veille (pour vérifier que ce n'est pas simplement l'écran qui s'éteint), mais la musique s'arrête et la machine se bloque.

3. Essayez votre machine avec un Live USB de 18.04 et vérifiez si vous avez les mêmes problèmes de suspension.

   • Cela permettra de confirmer que les problèmes de suspension ne sont pas liés à des programmes supplémentaires que vous avez installés.

   • Dans mon cas, j'ai soupçonné que c'était parce que j'avais installé tlp qui pourrait avoir interféré avec le mode de suspension d'une manière ou d'une autre, mais le même comportement s'est produit avec une clé USB live d'Ubuntu 18.04 et de Kubuntu 18.04.

4. Essayez les deux autres solutions bien documentées fournies ici par monty47 et StrangeNoises et voyez si vous obtenez de bons résultats.

   • Ils semblent avoir aidé un certain nombre de personnes à rétablir et à faire fonctionner correctement le système de suspension sous la version 18.04. s2idle plutôt que le sommeil (profond) d'une "suspension" habituelle.

5. Si aucune de ces solutions ne permet de résoudre vos problèmes de suspension sous 18.04, essayez la réponse acceptée à cette question : Ubuntu 18.04 se bloque lors d'une reprise depuis une suspension

   • La solution fournie par Matalak (qui a également posé la question) consistait à utiliser UKUU pour essayer un ancien noyau 4.14.

   • Ma machine à problème n'avait aucun problème de suspension avec Ubuntu 17.10 et Kubuntu 17.10, ce qui est logique puisque la version 17.10 utilise le noyau 4.14. Elle se suspend maintenant sans problème dans Ubuntu 18.04 et Kubuntu 18.04 en utilisant le noyau 4.14.

6. Si vous avez essayé les autres solutions et que vous n'avez pu résoudre vos problèmes de suspension qu'en revenant à un noyau 4.14, vous pourriez être intéressé par le rapport de bogue : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1774950

   • Il semble qu'il n'affecte que quelques machines avec une combinaison spécifique de matériel et peut être difficile à identifier parmi d'autres problèmes liés à nouveau ou à s2idle.

   • Il semble être plus fréquent pour ceux qui utilisent un Celeron/Pentium Atom Bay Trail, mais d'autres ont signalé un problème similaire avec d'autres machines.

   • Si vous êtes en mesure de vérifier votre kern.log après l'échec de cette suspension (c'est-à-dire une fois que vous avez dû éteindre votre machine et la redémarrer). vous remarquerez qu'il est écrit PM : suspendre l'entrée (profonde) et ensuite vous n'avez plus d'autres entrées à part les nombreuses lignes de redémarrage.

   • Il existe actuellement un correctif qui semble résoudre le problème.

   • Si vous avez envie d'ajouter votre voix au rapport de bogue, il serait intéressant de voir quelles machines particulières sont affectées (et de vérifier que le correctif corrige le problème pour tout le monde).

J'essaie également de regrouper les problèmes de suspension dans la version 18.04 dans ce fil de discussion : https://ubuntuforums.org/showthread.php?t=2395562&p=13780724#post13780724

Je veux juste ajouter une réponse aux utilisateurs du Thinkpad X1 Carbon 6ème génération qui a une symptôme similaire c'est-à-dire l'épuisement de la batterie pendant la suspension, qui est également dû au fait que l'on n'entre pas dans le système. profond mode veille.

Cette question est discutée sur ce fil de discussion sur le forum de Lenovo En bref, le X1C6 a choisi de prendre en charge Windows Modern Standby. Si vous lisez attentivement ce fil de discussion, vous verrez que bien que le symptôme soit partagé, les causes profondes varient grandement entre le XPS 13 9370 et le X1C6 . par exemple, la sortie de cat /sys/power/mem_sleep sur le X1C6 serait seulement [s2idle] indiquant un support manquant pour deep dormir.

Les solutions postées jusqu'à présent pour cette question s'appliquent uniquement au XPS 13, et non au X1C6. D'après ce que j'ai compris, la meilleure solution au problème du mode de suspension du X1C6 est d'appliquer un programme d'arrêt d'urgence. DSDT patch donné en premier lieu par Delta Xi et mis à jour ultérieurement par PombeirP . Ce poste vous explique comment appliquer le correctif, mais assurez-vous de lire l'article et toutes ses mises à jour avant toute action.

J'ai écrit un aperçu documentant les problèmes liés à l'installation d'Ubuntu 18.04 sur le Thinkpad X1 Carbon 6e génération, y compris les solutions que j'ai trouvées au problème de démarrage lent causé par LVM, ainsi que ce problème de sommeil profond .

Je pense que ce bug du noyau est lié :

https://bugzilla.kernel.org/show_bug.cgi?id=199689

Voir en particulier le commentaire n° 3 :

[ ] c'est en fait intentionnel d'utiliser s2idle sur cette machine avec le dernier noyau amont.