☰

Os kernels 5.5.10 e 5.5.11 do Fedora 31 falham ao tentar descriptografar o sistema de arquivos raiz luks após a atualização do kernel, mas o kernel 5.5.8 funciona

tag-icon • tag-icon fedora systemd kernel luks cryptsetup
Os kernels 5.5.10 e 5.5.11 do Fedora 31 falham ao tentar descriptografar o sistema de arquivos raiz luks após a atualização do kernel, mas o kernel 5.5.8 funciona

Após atualizar para o kernel 5.5.10-200.fc31, o Fedora 31 não consegue descriptografar o sistema de arquivos raiz na inicialização. Depois de inserir a senha de descriptografia, o sistema de arquivos não consegue descriptografar. O mesmo acontece com o kernel 5.5.11. Porém, se eu inicializar com o kernel 5.5.8 não há problema. Estas são as mensagens de erro que recebo com 5.5.11 ao executar 'journalctl':

localhost.localdomain systemd-cryptsetup[436]: device-mapper: reload ioctl on   failed: Invalid argument
localhost.localdomain kernel: device-mapper: table: 253:0: crypt: unknown target type
localhost.localdomain kernel: device-mapper: ioctl: error adding target to table
localhost.localdomain systemd-cryptsetup[436]: Failed to activate with specified passphrase: Invalid argument
localhost.localdomain systemd[1]: systemd-cryptsetup@luks\.... .service: Main process exited, code=exited, status=1/FAILURE
localhost.localdomain systemd[1]: systemd-cryptsetup@luks\.... .service: Failed with result 'exit-code'.
localhost.localdomain systemd[1]: Failed to start cryptography setup for luks-....
localhost.localdomain systemd[1]: Dependency failed for Local Encrypted Volumes.
localhost.localdomain systemd[1]: Job cryptsetup.target/start failed with result 'dependency'

Deixei de fora os IDs do luks enquanto digito isso manualmente. Qualquer ajuda será apreciada!

Responder1

Você deveria ir atéhttps://bugzilla.redhat.come relate isso como um bug. É muito improvável que possamos ajudar aqui.

O único conselho (por enquanto) é excluir o(s) kernel(s) ofensivo(s) mais antigo(s), para que você mantenha apenas o último e um (ou dois) kernels em funcionamento, dessa forma uma atualização não apagará um kernel em funcionamento.

Responder2

Para qualquer outra pessoa que esteja enfrentando esse problema - consegui resolvê-lo:

  1. Inicializando em um kernel funcional e removendo todos os softwares que foram instalados a partir de arquivos rpm independentes.

  2. (Enquanto ainda inicializado a partir do kernel funcional mais antigo) regenerando o initramfs para o kernel mais recente usando dracut, no meu caso foi para 5.5.11:

    sudo dracut /boot/initramfs-5.5.11-200.fc31.x86_64.img 5.5.11-200.fc31.x86_64

informação relacionada