☰

Los kernels 5.5.10 y 5.5.11 de Fedora 31 fallan al intentar descifrar el sistema de archivos raíz luks después de la actualización del kernel, pero el kernel 5.5.8 funciona

tag-icon • tag-icon fedora systemd kernel luks cryptsetup
Los kernels 5.5.10 y 5.5.11 de Fedora 31 fallan al intentar descifrar el sistema de archivos raíz luks después de la actualización del kernel, pero el kernel 5.5.8 funciona

Después de actualizar al kernel 5.5.10-200.fc31, Fedora 31 no puede descifrar el sistema de archivos raíz al arrancar. Después de ingresar la frase de contraseña de descifrado, el sistema de archivos no logra descifrar. Lo mismo ocurre con el kernel 5.5.11. Sin embargo, si inicio con el kernel 5.5.8 no hay problema. Estos son los mensajes de error que recibo con 5.5.11 cuando ejecuto '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'

Omití los identificadores de luks mientras escribo esto a mano. ¡Cualquier ayuda apreciada!

Respuesta1

Deberías dirigirte ahttps://bugzilla.redhat.come informar esto como un error. Es muy poco probable que aquí podamos ayudar.

El único consejo (por ahora) es eliminar los núcleos infractores más antiguos, de modo que solo conserve el último y uno (o dos) núcleos en funcionamiento, de esa manera una actualización no borrará un núcleo en funcionamiento.

Respuesta2

Para cualquier otra persona que tenga este problema, pude resolverlo de la siguiente manera:

  1. Arrancar en un kernel en funcionamiento y eliminar todo el software que se había instalado desde archivos rpm independientes.

  2. (Mientras todavía arranca desde el kernel anterior en funcionamiento) regenerando initramfs para el kernel más reciente usando dracut, en mi caso esto fue para 5.5.11:

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

información relacionada