Échec de la reprise en veille prolongée sur le noyau Linux 4.9.0, Debian 9

J'ai récemment mis à jour mon noyau de 3.16.4 (Debian Jessie) à 4.9.0 (Debian Stretch). Tout allait bien, jusqu'à ce que j'essaie de "Hibernate" (suspendre sur le disque).

Lorsque j'utilise l'option Hibernate dans LXDE, elle semble hiberner. J'entends la broche du disque tourner et écrire des données. Mais les problèmes apparaissent lors de la reprise de l'hibernation. Le noyau réussit à restaurer l'image à partir du swap, puis se fige et redémarre, avec tout ce travail perdu. Je n'ai pu trouver de réponse nulle part sur Internet. Les gens sont en train de résoudre quelques erreurs en ne définissant pas /etc/initramfs-tools/conf.d/resume ou en définissant des paramètres de noyau, ou en ayant une entrée incorrecte dans / etc / fstab. Je les ai correctes. Corrigez l'UUID dans /etc/initramfs-tools/conf.d/resume, corrigez fstab et ne définissez pas le paramètre de reprise du noyau.

• J'ai déplacé la partition de swap en dehors de la partition étendue vers la partition principale. L'UUID a été enregistré et appliqué au nouveau swap.

• Le système atteint "Restaurer l'image à 100%" puis "Suspendre les consoles", puis il s'éteint et démarre normalement, avec tout le travail perdu.

• Installation propre éprouvée, mais sans chance.

• Ne se produit que sur i386 (32 bits x86), amd64 (64 bits x86) ne souffre pas.

Disposition de la table de partition du disque:

NAME   FSTYPE LABEL    UUID                                 MOUNTPOINT
sda                                                         
├─sda1 ext4   HDD      <ROOT-UUID> /
└─sda2 swap   HDD-SWAP <SW-UUID> [SWAP]
sr0

Le sda2 était logique (réside à l'intérieur étendu) avant la mise à niveau.

Fstab:

UUID=<ROOT-UUID> / ext4 errors=remount-ro 0 1
UUID=<SW-UUID> none swap sw 0 0

/etc/initramfs-tools/conf.d/resume

RESUME=UUID=<SW-UUID>

Ligne de commande du noyau

BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-686-pae root=UUID=<ROOT-UUID> ro quiet

Informations système:

Computer: Compaq CQ60-120ec
Swap Size: 3.5GiB
Processor: AMD Athlon X2 64 QL-66
GPU: Nvidia Geforce 8200M G
Memory: 2G DDR2 667MHz
Desktop Environment: LXDE
Debian Version: 9 (stretch)
Kernel version: 4.9.0-3
Graphics Driver: nvidia legacy 304xxx

(Je sais que le processeur est 64 bits, mais il était fourni avec un système d'exploitation 32 bits à l'origine, donc je pensais que c'était 32 bits jusqu'à ce que j'examine / proc / cpuinfo)

Le problème est dû à un conflit entre hibernate et kASLR sur x86-32 . Cela peut être résolu en désactivant kASLR avec l' option d'amorçage du noyau nokaslr . x86-64 n'est pas affecté.

Pour Grub, cela peut être fait en éditant / etc / default / grub et en ajoutant nokaslr aux options de démarrage, par exemple: GRUB_CMDLINE_LINUX_DEFAULT = "quiet nokaslr "

Ensuite, exécutez update-grub pour mettre à jour la configuration et redémarrez pour l'essayer.

J'ai eu exactement le même problème et il semble que seul le noyau PAE soit affecté par ce problème. Le même noyau sans PAE fonctionne sans problème.

La solution de contournement pour moi a été d'installer linux-image-686 et de désinstaller linux-image-686-pae et linux-image-4.9.0-4-686-pae. La version exacte du noyau peut changer au fil du temps en raison des mises à niveau, mais fondamentalement le noyau PAE en cours d'exécution doit être remplacé par un noyau sans PAE.

Cela n'a en fait rien à voir avec le support PAE du CPU, car mon CPU supporte PAE selon / proc / cpuinfo. Mais le PAE n'est de toute façon pas très utile sur les vieux cahiers.

Cela n'a rien à voir avec le noyau 4.9 PAE car le même problème se produit avec le noyau 4.13 PAE des backports Debian.

Veut probablement /etc/uswsusp.confune entrée modifiée pour le `` périphérique de reprise '', si elle n'est pas utilisée, myabe essaie simplement de récupérer votre ancien UUID dans tous les fichiers /etcpour trouver un endroit où un changement est nécessaire. Un update-initramfsserait également nécessaire, je dirais.

J'obtenais la même erreur. La réinstallation avec la dernière iso netinst, c'est-à-dire debian-9.1.0-amd64-netinst.iso, l'a triée. Le bogue semble avoir été corrigé (au moins pour cette architecture).

J'ai supprimé uswsusp et l'hibernation fonctionne à nouveau comme un charme. BTW Je pense que c'était déjà le cas avant Jessie lorsque j'utilisais le pilote nvidia, j'ai testé en utilisant uswsusp et j'ai dû le supprimer pour que l'hibernation fonctionne.

Si vous avez une partition de swap (avec une taille correcte) et si vous éditez "/etc/initramfs-tools/conf.d/resume" avec quel résultat "#blkid" et i386 n'hibernera pas correctement que c'est un bug sur Debians i386 4.9 noyau! Mettez à jour le noyau vers une version supérieure à 4,9 ou restaurez le noyau 3.16.

Veuillez excuser le caractère générique de cette réponse. J'ai vu des questions similaires partout sur le Web et j'ai décidé d'écrire une réponse pour tous. J'ai rencontré le même problème que la mise à niveau de Debian-Jessie sur un Hp2510. Je suis passé à Ubuntu-desktop et je l'ai trouvé là aussi. J'ai par la suite fait mes tests sur Ubuntu et le Hp2510, donc cela peut ne pas s'appliquer complètement à votre situation.

Certains ordinateurs plus anciens mis à jour avec de nouveaux systèmes Linux rencontrent des problèmes de démarrage. Il se peut qu'ils ne démarrent pas du tout ou que leur démarrage prenne trois minutes. Par coïncidence, ils ne parviennent pas à hiberner ou mettent tellement de temps à hiberner et à se déshonorer que la capacité est inutile. Souvent, ce n'est pas parce que les anciens ordinateurs sont tout simplement lents, mais à cause d'un changement introduit dans le noyau Linux 4.8, provoquant un problème avec un chipset Intel très courant, qui inclut une sortie svideo. À partir de ce noyau, tout ordinateur avec ce chipset rencontrera des problèmes de démarrage sauf si l'argument de ligne de commande Linux"video=SVIDEO-1:d"est inclus dans GRUB_CMDLINE_LINUX. Cela raccourcira considérablement les temps de démarrage 64 bits et 32 ​​bits, mais ne résout les problèmes de mise en veille prolongée que pour 64 bits. Aucun système 32 bits ne prend en charge la mise en veille prolongée après ce point. De plus, les temps de démarrage pour toutes les versions du noyau 4.8 et 4.9 sont mauvais (sauf 4.8.rc1-7). Ceci est finalement résolu en 4.10. Les noyaux 4.8 et 4.9 doivent être évités (ils sont de toute façon obsolètes).

Si vous voulez les temps de démarrage les plus rapides, utilisez un noyau pré-4.8. J'utiliserais Ubuntu-desktop 15.04 avec un noyau mis à jour en 4.7.10. C'est le seul moyen d'obtenir l'hibernation dans un système 32. Le système 64 bits démarre 7% plus lentement que le 32 bits, mais il est toujours plus rapide que toute version ultérieure. Si vous voulez un système 32 bits actuellement pris en charge et que vous êtes prêt à renoncer à l'hibernation, utilisez tous ceux qui sont publiés ou mis à jour vers un noyau 4.10 ou ultérieur. Toute version 64 bits fonctionne après 4.8 avec le correctif vidéo, mais pour de meilleures performances, évitez 4.8 et 4.9.

Pour ajouter le correctif vidéo, faites sudo nano /etc/default/grub. Après avoir fermé nano do sudo update-grub. À moins que GRUB_CMDLINE_LINUX_DEFAULT, qui est inséré après GRUB_CMDLINE_LINUX, soit vide, "video=SVIDEO-1:d"ne sera pas le dernier argument de ligne de commande Linux, ce que certains disent nécessaire. Cela peut être n'importe où.

Vous pouvez toujours invoquer hibernate avec la commande pm-hibernate dans un terminal (ou tty) mais pour avoir une option GUI disponible, vous devez créer ou ajouter au fichier de stratégie /etc/polkit-1/localauthority/50-local.d/ com.ubuntu.enable-hibernate.pkla(évidemment spécifique à la distribution) le texte suivant:

[Re-enable hibernate by default for login1]
    Identity=unix-user:*
    Action=org.freedesktop.login1.hibernate
    ResultActive=yes
[Re-enable hibernate for multiple users by default in logind]
    Identity=unix-user:*
    Action=org.freedesktop.login1.hibernate-multiple-sessions
    ResultActive=yes

Parfois, le problème n'est pas dans le ver ou l'UUID. Cela se produit également lorsque vous manquez d'espace de stockage. Il n'y aura plus d'espace d'écriture, la reprise de l'hibernation se bloquera.

Lorsque vous arrivez à cette erreur, vous pouvez cliquer sur alt+ f2/f3/f7ou ctrl+alt+ f2/f3/f7pour ouvrir le terminal. Connectez-vous à votre compte ou root en utilisant le terminal.

Exécutez ensuite la commande sudo df -hpour vérifier l'espace de stockage. Dans mon cas, je n'avais pas d'espace sur mon /dev/sda1donc vérifiez l'espace libre sur les lecteurs de la liste.

Si vous manquez d'espace, essayez de supprimer certains fichiers pour obtenir une quantité considérable d'espace.

Après cela, vous pouvez cliquer sur alt+f1ou ctrl+alt+f1et attendre que l'interface de connexion apparaisse ou taperreboot in the terminal to reboot