Error de reanudación de hibernación en Linux kernel 4.9.0, Debian 9

Recientemente actualicé mi kernel de 3.16.4 (Debian jessie) a 4.9.0 (Debian stretch). Todo estuvo bien, hasta que intenté "Hibernar" (suspender en el disco).

Cuando uso la opción Hibernar en LXDE, parece que hiberna. Puedo escuchar el eje del disco haciendo tictac y escribiendo datos. Pero los problemas aparecen cuando se reanuda la hibernación. El núcleo restaura con éxito la imagen del intercambio, pero luego se congela y reinicia, con todo ese trabajo perdido. No pude encontrar la respuesta en ninguna parte de internet. La gente simplemente está resolviendo algunos errores en torno a no configurar /etc/initramfs-tools/conf.d/resume o haber configurado los parámetros del kernel o tener una entrada incorrecta en / etc / fstab. Tengo estos correctos. Corrija el UUID en /etc/initramfs-tools/conf.d/resume, corrija fstab y no configure el parámetro de reanudar el kernel.

• Moví la partición de intercambio fuera de la partición extendida a primaria. El UUID se guardó y se aplicó al nuevo intercambio.

• El sistema alcanza "Restaurar imagen al 100%" y luego "Suspender consolas", y luego se apaga y arranca normalmente, con todo el trabajo perdido.

• Intenté instalar limpio, pero sin suerte.

• Solo sucede en i386 (32 bits x86), amd64 (64 bits x86) no sufre.

Diseño de tabla de partición de disco:

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

El sda2 era lógico (reside-dentro-extendido) antes de la actualización.

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>

Kernel cmdline

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

Información del sistema:

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

(Sé que el procesador es de 64 bits, pero originalmente tenía 32 bits de sistema operativo, así que pensé que era de 32 bits hasta que examiné / proc / cpuinfo)

El problema se debe a un conflicto entre hibernate y kASLR en x86-32 . Esto se puede resolver deshabilitando kASLR con la opción de arranque del kernel nokaslr . x86-64 no se ve afectado.

Para Grub, esto se puede hacer editando / etc / default / grub y agregando nokaslr a las opciones de arranque, por ejemplo: GRUB_CMDLINE_LINUX_DEFAULT = "quiet nokaslr "

Luego ejecute update-grub para actualizar la configuración y reinicie para intentarlo.

Tuve exactamente el mismo problema y parece que solo el núcleo PAE se ve afectado por ese problema. El mismo núcleo sin PAE funciona sin problemas.

La solución para mí fue instalar linux-image-686 y desinstalar linux-image-686-pae y linux-image-4.9.0-4-686-pae. La versión exacta del kernel puede cambiar con el tiempo debido a las actualizaciones, pero básicamente el kernel PAE que se está ejecutando actualmente debe reemplazarse por un kernel sin PAE.

En realidad, no tiene nada que ver con el soporte PAE de la CPU, ya que mi CPU admite PAE de acuerdo con / proc / cpuinfo. Pero PAE de todos modos no es de mucha utilidad en los viejos portátiles.

Tampoco tiene nada que ver con el kernel 4.9 PAE ya que ocurre el mismo problema con el kernel 4.13 PAE de los puertos de Debian.

Probablemente /etc/uswsusp.confquiera una entrada modificada para el 'dispositivo de reanudación', si esto no se usa, myabe solo intente agrupar su UUID anterior en todos los archivos /etcpara encontrar un lugar donde se necesite un cambio. También update-initramfssería necesario, diría yo.

Estaba recibiendo el mismo error. Reinstalar con la última iso de netinst, es decir, debian-9.1.0-amd64-netinst.iso lo solucionó. El error parece haberse solucionado (al menos para esta arquitectura).

Eliminé uswsusp e hibernación funciona de nuevo como un encanto. Por cierto, creo que ya era el caso antes de Jessie cuando estaba usando el controlador nvidia, probé usando uswsusp y tuve que eliminarlo para que la hibernación funcionara.

Si tiene una partición de intercambio (con el tamaño correcto) y edita "/etc/initramfs-tools/conf.d/resume" con el resultado "#blkid" y i386 no hibernará correctamente, ya que es un error en Debians i386 4.9 núcleo ! Actualice el kernel a una versión superior a 4.9 o regrese a 3.16 kernel.

Disculpe la naturaleza genérica de esta respuesta. He visto preguntas similares en toda la Web y decidí escribir una respuesta para todos. Encontré el mismo problema al actualizar Debian-Jessie en un Hp2510. Cambié al escritorio de Ubuntu y lo encontré allí también. Posteriormente hice mis pruebas en Ubuntu y el Hp2510, por lo que es posible que no se aplique completamente a su situación.

Algunas computadoras antiguas actualizadas con nuevos sistemas Linux experimentan problemas de arranque. Es posible que no se inicien en absoluto o que tarden hasta tres minutos en iniciarse. Casualmente, fallan en hibernar o tardan tanto en hibernar y deshiberinar que la capacidad es inútil. A menudo, esto no se debe a que las computadoras viejas son simplemente lentas, sino a un cambio introducido en el kernel de Linux 4.8, que causa un problema con un chipset Intel muy común, que incluye salida de video. Comenzando con este kernel, cualquier computadora con este chipset experimentará problemas de arranque a menos que el argumento de la línea de comando de Linux"video=SVIDEO-1:d"está incluido en GRUB_CMDLINE_LINUX. Esto acortará significativamente los tiempos de arranque de 64 bits y 32 bits, pero corrige los problemas de hibernación solo para 64 bits. Ningún sistema de 32 bits admite hibernación después de este punto. Además, los tiempos de arranque para todas las versiones de kernel 4.8 y 4.9 son malos (excepto 4.8.rc1-7). Esto finalmente se resuelve en 4.10. Los núcleos 4.8 y 4.9 simplemente deben evitarse (de todos modos son obsoletos).

Si desea los tiempos de arranque más rápidos, use un núcleo anterior a 4.8. Usaría Ubuntu-desktop 15.04 con el kernel actualizado a 4.7.10. Esta es la única forma de hibernar en un sistema de 32. El sistema de 64 bits arranca un 7% más lento que el de 32 bits, pero sigue siendo más rápido que cualquier versión posterior. Si desea un sistema de 32 bits actualmente compatible y está dispuesto a renunciar a la hibernación, use cualquiera que se publique o actualice a un kernel 4.10 o posterior. Cualquier versión de 64 bits funciona después de 4.8 con la corrección de video, pero para un mejor rendimiento, evite 4.8 y 4.9.

Para agregar el video, hazlo sudo nano /etc/default/grub. Después de cerrar nano do sudo update-grub. A menos que GRUB_CMDLINE_LINUX_DEFAULT, que se inserta después de que GRUB_CMDLINE_LINUX, esté en blanco, "video=SVIDEO-1:d"no será el último argumento de la línea de comandos de Linux, que algunas personas dicen que es necesario. En realidad puede estar en cualquier parte.

Siempre puede invocar hibernate con el comando pm-hibernate en un terminal (o tty), pero para tener una opción de GUI disponible, debe crear o agregar al archivo de políticas /etc/polkit-1/localauthority/50-local.d/ com.ubuntu.enable-hibernate.pkla(obviamente específico de la distribución) el siguiente texto:

[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

A veces el problema no está en el grub o UUID. Esto también sucede cuando no tiene espacio de almacenamiento. No quedará espacio de escritura, por lo tanto, la reanudación de la hibernación se congelará.

Cuando llegue a ese error, puede hacer clic en alt+ f2/f3/f7o ctrl+alt+ f2/f3/f7para abrir la terminal. Inicie sesión en su cuenta o root usando la terminal.

Luego ejecute el comando sudo df -hpara verificar el espacio de almacenamiento. En mi caso no tenía espacio en mi, /dev/sda1así que verifique el espacio libre en las unidades de la lista.

Si no tiene espacio, intente eliminar algunos archivos para obtener una cantidad considerable de espacio.

Después de eso, puede hacer clic en alt+f1o ctrl+alt+f1y esperar a que aparezca la GUI de inicio de sesión o escribareboot in the terminal to reboot