Falha no resumo da hibernação no kernel linux 4.9.0, Debian 9

Recentemente, atualizei meu kernel da 3.16.4 (Debian jessie) para 4.9.0 (Debian stretch). Tudo estava bem, até que eu tentei "Hibernar" (suspender no disco).

Quando uso a opção Hibernar no LXDE, ela parece hibernar. Eu posso ouvir o fuso do disco passando e escrevendo dados. Mas os problemas aparecem ao sair da hibernação. O kernel restaura com sucesso a imagem do swap, mas congela e reinicia, com todo o trabalho perdido. Não consegui encontrar resposta em nenhum lugar da internet. As pessoas estão apenas resolvendo alguns erros ao não configurar o /etc/initramfs-tools/conf.d/resume ou configuraram os parâmetros do kernel ou têm uma entrada incorreta no / etc / fstab. Eu tenho isso correto. Corrija o UUID em /etc/initramfs-tools/conf.d/resume, corrija o fstab e não defina o parâmetro de retorno do kernel.

• Mudei a partição de swap para fora da partição estendida para primária. O UUID foi salvo e aplicado à nova troca.

• O sistema alcança "Restaurando a imagem 100%" e, em seguida, "Suspendendo consoles" e, em seguida, desliga e inicializa normalmente, com todo o trabalho perdido.

• Tentei instalar limpo, mas sem sorte.

• Acontece apenas no i386 (x86 de 32 bits), o amd64 (x86 de 64 bits) não sofre.

Layout da tabela de partição do disco:

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

O sda2 era lógico (reside dentro do estendido) antes da atualização.

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>

Cmdline do kernel

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

Informação do 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

(Eu sei que o processador é de 64 bits, mas veio originalmente com 32 bits do sistema operacional, então eu pensei que era de 32 bits até examinar / proc / cpuinfo)

O problema ocorre devido a um conflito entre o hibernate e o kASLR no x86-32 . Isso pode ser resolvido desativando o kASLR com a opção de inicialização do kernel nokaslr . x86-64 não é afetado.

Para o Grub, isso pode ser feito editando / etc / default / grub e adicionando nokaslr às opções de inicialização, por exemplo: GRUB_CMDLINE_LINUX_DEFAULT = "quiet nokaslr "

Em seguida, execute o update-grub para atualizar a configuração e reinicialize para tentar.

Eu tinha exatamente o mesmo problema e parece que apenas o kernel do PAE é afetado por esse problema. O mesmo kernel sem PAE funciona sem problemas.

A solução alternativa para mim foi instalar o linux-image-686 e desinstalar o linux-image-686-pae e o linux-image-4.9.0-4-686-pae. A versão exata do kernel pode mudar com o tempo devido a atualizações, mas basicamente o kernel do PAE atualmente em execução precisa ser substituído por um kernel sem o PAE.

Na verdade, não tem nada a ver com o suporte PAE da CPU, pois minha CPU suporta PAE de acordo com / proc / cpuinfo. Mas o PAE não é de muita utilidade em notebooks antigos.

Também não tem nada a ver com o kernel 4.9 PAE, pois o mesmo problema ocorre com o kernel 4.13 PAE dos backports Debian.

Provavelmente, /etc/uswsusp.confquer uma entrada alterada para o 'dispositivo de retomada', se isso não for usado, myabe apenas tente cumprimentar seu antigo UUID em todos os arquivos /etcpara encontrar um local onde a mudança é necessária. Também update-initramfsseria necessário, eu diria.

Eu estava recebendo o mesmo erro. Reinstalando com o mais recente netinst iso, ou seja, o debian-9.1.0-amd64-netinst.iso resolveu o problema. O erro parece ter sido corrigido (pelo menos para esta arquitetura).

Eu removi o uswsusp e a hibernação funciona novamente como um encanto. BTW Acho que já era o caso de Jessie quando eu estava usando o driver da nvidia, testei usando o uswsusp e precisei removê-lo para que a hibernação funcionasse.

Se você tiver uma partição swap (com tamanho correto) e se editar "/etc/initramfs-tools/conf.d/resume" com o que resultado "#blkid" e o i386 não hibernará corretamente, é um bug no Debians i386 4.9 núcleo ! Atualize o kernel para uma versão maior que 4.9 ou reverta para o kernel 3.16.

Por favor, desculpe a natureza genérica desta resposta. Vi perguntas semelhantes em toda a Web e decidi escrever uma resposta para todos. Eu encontrei o mesmo problema ao atualizar o Debian-Jessie em um Hp2510. Eu mudei para o Ubuntu-desktop e o encontrei lá também. Posteriormente, fiz meus testes no Ubuntu e no Hp2510, para que ele não se aplique completamente à sua situação.

Alguns computadores antigos atualizados com os novos sistemas Linux enfrentam problemas de inicialização. Eles podem não ser inicializados ou podem levar até três minutos para serem inicializados. Coincidentemente, eles não conseguem hibernar ou demoram tanto para hibernar e desibernar que a capacidade é inútil. Frequentemente, isso não ocorre porque computadores antigos são simplesmente lentos, mas devido a uma alteração introduzida no kernel 4.8 do Linux, causando um problema com um chipset Intel muito comum, que inclui saída svideo. A partir deste kernel, qualquer computador com esse chipset terá problemas de inicialização, a menos que o argumento da linha de comando do Linux"video=SVIDEO-1:d"está incluído no GRUB_CMDLINE_LINUX. Isso reduzirá significativamente os tempos de inicialização de 64 e 32 bits, mas corrigirá os problemas de hibernação apenas para os de 64 bits. Nenhum sistema de 32 bits suporta hibernação após esse ponto. Além disso, os tempos de inicialização para todas as versões do kernel 4.8 e 4.9 são ruins (exceto 4.8.rc1-7). Isso finalmente foi resolvido na versão 4.10. Os núcleos 4.8 e 4.9 devem ser evitados (eles são obsoletos de qualquer maneira).

Se você deseja tempos de inicialização mais rápidos, use um kernel anterior à 4.8. Eu usaria o Ubuntu-desktop 15.04 com o kernel atualizado para 4.7.10. Essa é a única maneira de obter a hibernação em um sistema de 32. O sistema de 64 bits é inicializado 7% mais lento que o de 32 bits, mas ainda é mais rápido que em qualquer versão posterior. Se você deseja um sistema de 32 bits atualmente suportado e deseja renunciar à hibernação, use qualquer um que seja lançado ou atualizado para um kernel 4.10 ou posterior. Qualquer versão de 64 bits funciona após o 4.8 com a correção de vídeo, mas para obter o melhor desempenho, evite 4.8 e 4.9.

Para adicionar a correção de vídeo faça sudo nano /etc/default/grub. Depois de fechar o nano do sudo update-grub. A menos que GRUB_CMDLINE_LINUX_DEFAULT, que é inserido após GRUB_CMDLINE_LINUX, esteja em branco, "video=SVIDEO-1:d"não será o último argumento de linha de comando do Linux, que algumas pessoas consideram necessário. Na verdade, pode estar em qualquer lugar.

Você sempre pode chamar o hibernate com o comando pm-hibernate em um terminal (ou tty), mas para ter uma opção disponível da GUI, é necessário criar ou adicionar ao arquivo de políticas /etc/polkit-1/localauthority/50-local.d/ com.ubuntu.enable-hibernate.pkla(obviamente específico da distribuição) o seguinte 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

Às vezes, o problema não está no grub ou no UUID. Isso também acontece quando você está sem espaço de armazenamento. Não haverá espaço de gravação restante, portanto, a retomada da hibernação será congelada.

Quando você chegar a esse erro, você pode clicar alt+ f2/f3/f7ou ctrl+alt+ f2/f3/f7abrir o terminal. Entre na sua conta ou faça o root usando o terminal.

Em seguida, execute o comando sudo df -hpara verificar o espaço de armazenamento. No meu caso, não havia espaço no meu, /dev/sda1portanto, verifique o espaço livre nas unidades da lista.

Se você estiver sem espaço, tente excluir alguns arquivos para obter uma quantidade considerável de espaço.

Depois disso, você pode clicar em alt+f1ou ctrl+alt+f1e aguardar que a interface de usuário apareça ou digitereboot in the terminal to reboot