☰

Die Fedora 31-Kernel 5.5.10 und 5.5.11 schlagen beim Versuch fehl, das Luks-Root-Dateisystem nach einem Kernel-Update zu entschlüsseln, aber Kernel 5.5.8 funktioniert

tag-icon • tag-icon fedora systemd kernel luks cryptsetup
Die Fedora 31-Kernel 5.5.10 und 5.5.11 schlagen beim Versuch fehl, das Luks-Root-Dateisystem nach einem Kernel-Update zu entschlüsseln, aber Kernel 5.5.8 funktioniert

Nach dem Update auf Kernel 5.5.10-200.fc31 kann Fedora 31 das Root-Dateisystem beim Booten nicht entschlüsseln. Nach Eingabe der Entschlüsselungspassphrase schlägt die Entschlüsselung des Dateisystems fehl. Dasselbe passiert mit Kernel 5.5.11. Wenn ich jedoch mit Kernel 5.5.8 boote, gibt es kein Problem. Dies sind die Fehlermeldungen, die ich mit 5.5.11 erhalte, wenn ich „journalctl“ ausführe:

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'

Ich habe die Luks-IDs weggelassen, da ich dies von Hand eintippe. Jede Hilfe ist willkommen!

Antwort1

Gehen Sie zuhttps://bugzilla.redhat.comund melde dies als Fehler. Es ist sehr unwahrscheinlich, dass wir hier helfen können.

Der einzige Rat (im Moment) besteht darin, den/die ältesten fehlerhaften Kernel zu löschen, sodass Sie nur den allerletzten und einen (oder zwei) funktionierende Kernel behalten, sodass durch ein Update kein funktionierender Kernel gelöscht wird.

Antwort2

Für alle anderen, die auf dieses Problem stoßen – ich konnte es wie folgt lösen:

  1. Booten in einen funktionierenden Kernel und Entfernen aller Software, die aus eigenständigen RPM-Dateien installiert wurde.

  2. (Während noch vom älteren funktionierenden Kernel gebootet wurde) Neugenerierung von initramfs für den neuesten Kernel mit dracut, in meinem Fall war dies für 5.5.11:

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

verwandte Informationen