Falha na continuação da hibernação no kernel do linux 4.9.0, Debian 9

Question

Eu recentemente atualizei meu kernel do 3.16.4 (Debian jessie) para o 4.9.0 (Debian stretch). Tudo estava bem, até que eu tentei "Hibernar" (suspender para o disco).

Quando eu uso a opção Hibernate no LXDE, parece hibernar. Eu posso ouvir o fuso do disco passando e escrevendo dados. Mas os problemas aparecem quando sair da hibernação. O kernel restaura com sucesso a imagem da troca, mas depois congela e reinicia, com todo esse trabalho perdido. Não consegui encontrar resposta em nenhum lugar na internet. As pessoas estão apenas resolvendo alguns erros ao redor de não configurar /etc/initramfs-tools/conf.d/resume ou ter configurado parâmetros do kernel, ou ter entradas erradas em / etc / fstab. Eu tenho estes corretos. Corrija o UUID em /etc/initramfs-tools/conf.d/resume, corrija fstab e não defina o parâmetro de continuação do kernel.

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

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

• Tentativa de instalação limpa, mas sem sorte.

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

Layout da tabela de partição de 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-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 ele veio com 32 bits os originalmente, então eu pensei que era 32 bits até que eu examinei / proc / cpuinfo)

    

Answer 1

O problema é devido a um conflito entre o hibernate e kASLR em 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="silencioso nokaslr "

Em seguida, execute update-grub para atualizar a configuração e reboot para experimentá-lo.

Eu tive 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 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 PAE atualmente em execução precisa ser substituído por um kernel sem PAE.

Na verdade, não tem nada a ver com o suporte a PAE da CPU, já que minha CPU suporta PAE de acordo com / proc / cpuinfo. Mas o PAE não é de todo útil em notebooks antigos.

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

    

Answer 2

Provavelmente /etc/uswsusp.conf deseja uma entrada alterada para o 'dispositivo de continuação', se isso não for usado, myabe tente apenas fazer um grep antigo em todos os arquivos em /etc para encontrar um lugar onde a mudança é necessária. Também um update-initramfs seria necessário, eu diria.

    

Answer 3

Eu estava recebendo o mesmo erro. Reinstalando com o último netinst iso, ou seja, debian-9.1.0-amd64-netinst.iso resolvido. Bug parece ter sido corrigido (pelo menos para esta arquitetura).

    

Answer 4

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

    

Answer 5

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

    

Answer 6

Por favor, desculpe a natureza genérica desta resposta. Já vi perguntas semelhantes em toda a Web e decidi escrever uma resposta para todos. Eu encontrei o mesmo problema que você atualizando Debian-Jessie em um Hp2510. Eu mudei para o Ubuntu-desktop e encontrei lá também. Eu subseqüentemente fiz meus testes no Ubuntu e no Hp2510, então isso pode não se aplicar completamente à sua situação.

Alguns computadores mais antigos, atualizados com novos sistemas Linux, enfrentam problemas de inicialização. Eles podem não inicializar ou podem levar até três minutos para inicializar. Coincidentemente, ou eles não conseguem hibernar ou demoram tanto para hibernar e inibir que a capacidade é inútil. Frequentemente, isso não acontece porque os 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 a saída svideo. Começando com este kernel, qualquer computador com este chipset terá problemas de inicialização, a menos que o argumento de linha de comando do Linux "video=SVIDEO-1:d" esteja incluído no GRUB_CMDLINE_LINUX. Isso reduzirá significativamente os tempos de inicialização de 64 bits e 32 bits, mas corrigirá os problemas de hibernação apenas para 64 bits. Nenhum sistema de 32 bits suporta hibernação após este 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 resolvido no 4.10. Os kernels 4.8 e 4.9 devem ser evitados (de qualquer forma, são obsoletos).

Se você quiser os tempos de inicialização mais rápidos, use um kernel pré-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 32. O sistema de 64 bits é inicializado 7% mais lento que o de 32 bits, mas ainda é mais rápido que qualquer outra versão posterior. Se você quiser um sistema de 32 bits atualmente suportado e estiver disposto a abrir mão da hibernação, use qualquer um que seja liberado ou atualizado para um kernel 4.10 ou posterior. Qualquer versão de 64 bits funciona depois de 4.8 com a correção de vídeo, mas para 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 dizem ser necessário. Na verdade, pode ser em qualquer lugar.

Você sempre pode invocar o hibernate com o comando pm-hibernate em um terminal (ou tty), mas para ter uma opção de GUI disponível você precisa 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) 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