Kubuntu mit Luks verschlüsselt - Bootvorgang ruft Schlüsseleingabe nicht mehr auf

[ThommyDD]

Hallo zusammen,

ich habe mehrere Rechner mit Kubuntu LTS 24.04.3 laufen, jeweils mit verschlüsselt mit Luks. Bei allen Rechnern tritt früher oder später spontan das Problem auf, dass beim Boot die Schlüsseleingabe für Luks nicht mehr aufgerufen wird. Ich lande dann im initramfs-Bildschirm. Bisher war das meist nach Kernelupdates das Problem, ich konnte dann aber in den erweiterten Startoptionen jeweils den älteren Kernel aufrufen und damit booten. Jetzt habe ich aber erstmals das Problem, dass es kein Kernelupdate gab und der ursprüngliche und einzige Kernel nicht mehr bootet, mit genau diesem Problem. Mich wundert, dass ich dazu im Netz überhaupt nichts finde, anscheinend niemand dieses Problem hat, bei mir tritt es aber gleich reihenweise auf, seit etwa einem Vierteljahr. Irgendwelche Ideen, das Problem zu fixen?

Die Rechner laufen mit UEFI-Boot, die GPT beinhaltet jeweils eine unverschlüsselte /boot/efi mit FAT32, eine unverschlüsselte /boot mit ext4 und eine verschlüsselte Rootpartition (/) mit ext4. Ist daran etwas falsch? Ich nutze Linux seit dreizehn Jahren auf diese Weise verschlüsselt, allerdings zunächst nur mit Legacy-Boot (dort natürlich ohne die /boot/efi). Erst mit UEFI-Boot kommt es meines Erachtens zu diesem Problem.

Viele Grüße
Thomas

 

[kieleich]

normalerweise ist bei sowas dann aus iwelchen gründen das Initramfs falsch gebaut oder falsche Kernelparameter. oder kernelversion und initrd version passen nicht zusammen, kernelmodule fehlen bzw sind für den falschen kernel im initrd

fall du in einer initrd shell landest mal cat /proc/cmdline ob die parameter so sind wie gedacht, uname -a welche kernelversion, und das mit lib modules version abgleichen

und cryptsetup befehl ist verfügbar? wobei das kein endgültiges indiz ist manchmal geht das über libcryptsetup ohne das cli tool

 

[ThommyDD]

Danke für deine Antwort! Puh, viele Sachen, mit denen ich noch nie zu tun hatte. 🤯 Ich versuche das mal umzusetzen. Aber wieso passiert sowas spontan? Der Rechner, bei dem es jetzt ganz krass ist, ist bei meinen Eltern. Die machen auch keine Updates, das mache ich immer, wenn ich da bin. Da bin ich mir also ziemlich sicher, dass da im Hintergrund eigentlich nichts kaputt gegangen sein kann durch Updates. Warum sollten dann plötzlich falsche Kernelparameter drin stehen? Zudem kenne ich die richtigen auch nicht, kann sie also schlecht prüfen, weil mir das, was ich da sehe, sehr wahrscheinlich nichts sagt.

 

[GTrash81]

Haben die Rechner ein TPM-Modul?

Bis Ubuntu 24.04.x waren die Pakete zu alt bzw. hatten Bugs, wodurch LUKS nicht mit TPM kooperieren wollte.
Ab 24.04.x+1 kamen die nötigen Updates raus und seitdem funktioniert LUKS mit TPM.
Meine Vermutung ist, dass nun nach den Updates das System zum Erbrechen versucht LUKS mit dem TPM-Modul zu öffnen.
Sollte normalerweise nicht passieren, weil man explizit Einstellungen vornehmen muss, aber der Code ist von Menschen gemacht und die machen auch Fehler.
Hier könnte es reichen die TPM-Funktion im BIOS/UEFI zu deaktivieren.

Alternative Vermutung ist, was ich auch schon mal hatte, dass das BIOS/UEFI bzw. TPM nicht sauber programmiert ist und nun nach den Updates dieser Missstand dem System auffällt.
Vielleicht hilft hier es auch die TPM-Funktion im BIOS/UEFI zu deaktivieren.

 

[kieleich]

ja gut dmesg reinschauen kann man auch noch, vielleicht ist es ein ganz anderes problem und die ssd geht langsam flöten

tpm luks wäre schräg, das kann nicht von selbst aktiv werden das muss man aktiv ausrollen, würde im luksdump dann auch was von stehen

was häufiger passierte bei ubuntu, /boot partition voll und dann, klappt das mit dem kernel initrd update nicht mehr. gerade bei alten installationen. /boot wird oft viel zu klein angelegt jedes megabyte einzeln abgezählt (?!) aber die kernelsachen werden mit jedem update größer. und dann kracht es

live cd, chroot und von dort aus freiputzen reparieren, je nachdem kernel neu installieren und update-initramfs neu ausführen

ich kann zu ubuntu sonst leider auch nicht mehr so viel sagen, was früher ubuntu war ist heute opensuse bei mir

 

[h2f]

...dass es kein Kernelupdate gab und der ursprüngliche und einzige Kernel nicht mehr bootet, mit genau diesem Problem

Nur zum Verständnis: normalerweise kann man doch in Grub immer auf eine ganze Auswahl vorheriger Kernel zugreifen? Wo sind die? Wurden die (manuell) entfernt? Wurde vielleicht etwas zuviel entfernt?

Wenn das Problem gleich "reihenweise" auftritt - hast du die Angewohnheit auf deinen Rechnern "aufzuräumen"?

Was noch passen könnte: der Datenträger steigt langsam aus. (Aber wieso dann gleich "reihenweise")

 

[ThommyDD]

Danke für eure Rückmeldungen.

TPM war ein interessanter Hinweis, jedoch habe ich bei den Rechnern TPM deaktiviert (nochmal geprüft). /boot ist 1GiB groß und hat noch über 700MiB frei, ist also auch nicht das Problem. Bei dem einen Rechner ist die SSD erst drei Monate alt, arbeitet ansonsten einwandfrei und bootet ja auch mit dem alten Kernel problemlos. Beim anderen Rechner ist die SSD schon älter, aber nicht ansatzweise in einem nennenswerten Alterungszustand. Das beschriebene Problem hatte ich auf einem dritten Rechner vor einigen Monaten, dort habe ich allerdings das System danach komplett neu installiert und kann das Problem daher nicht mehr untersuchen.

Dafür war der Hinweis mit den Bootparametern Gold wert. Zumindest bei einem Rechner konnte ich das Problem jetzt tatsächlich lösen. Das ist der, bei dem ich noch einen älteren Kernel hatte und booten konnte. Bei diesem Rechner hatte ich ja den direkten Vergleich der alten und neuen Bootparameter. Einst bekam ich damit die initramfs-Shell, jetzt aber nur noch eine Kernel Panic. Mag sein, dass ich zwischenzeitlich schon mal ein anderes Kernelupdate hatte, das bis zur initramfs-Shell kam und das jetzige Update nicht mal dahin. Kann ich nicht mehr mit Sicherheit sagen.

Der Grub-Eintrag für den alten Kernel sah folgendermaßen aus:

recordfail
load_video
gfxmode $linux_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set-root ****
echo 'Loading Linux 6.14.0-37-generic ...'
linux /vmlinuz-6.14.0-37-generic root=UUID=**** ro quiet cryptdevice=UUID=****:luks-**** root=/dev/mapper/luks-**** splash $vt_handoff
echo 'Loading initial ramdisk ...'
initrd /initrd.img-6.14.0-37-generic

Der Eintrag für den neuen Kernel hingegen hatte einen etwas anderen Aufbau:

recordfail
load_video
gfxmode $linux_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set-root ****
echo 'Loading Linux 6.17.0-14-generic ...'
linux /vmlinuz-6.17.0-14-generic root=/dev/mapper/luks-**** ro quiet cryptdevice=UUID=****:luks-**** root=/dev/mapper/luks-**** splash $vt_handoff

Die verschlüsselte Rootpartition wurde also im ersten Parameter nicht mit root=UUID= aufgerufen, sondern mit root=/dev/mapper/luks. (Die genauen IDs habe ich mit Sternchen gekürzt.) Zudem fehlte der Befehl zum Laden der Ramdisk. Ich habe dann den Grub-Befehl beim Start editiert, den /dev/mapper/-Aufruf durch den ursprünglichen UUID-Aufruf mit der korrekten ID ersetzt und den Befehl zum Aufruf der Ramdisk ergänzt. Der ganze GRUB-Eintrag sah dann genauso aus wie beim alten Kernel mit Ausnahme der Kernelversion.

Damit kam ich immerhin so weit, dass beim Bootvorgang die Meldung kam, dass die Datei initrd.img-6.17.0-14-generic nicht gefunden werden könnte. Daraufhin habe ich /boot überprüft, und richtig, diese Datei fehlte. Alle anderen Kerneldateien schienen da zu sein.

Daraufhin habe ich wieder den alten Kernel gebootet und dann den neueren Kernel über die Paketverwaltung vollständig entfernt. Beim manuellen Neuinstallieren des neueren Kernels kam dann eine Fehlermeldung, die auf eine Inkompatibilität mit VirtualBox hinwies (installiert war Version 7.1). Weitere Recherche ergab, dass der 6.17er Kernel mindestens Virtualbox 7.2 erfordert. Also Virtualbox aktualisiert, dann lief auch das Kernelupdate ohne Fehler durch.

Zur Klarstellung: Es geht nicht um ein Kernelupdate in einer virtuellen Maschine (Gastsystem). Es geht um das Kernelupdate im Wirtssystem, das durch das installierte VirtualBox korrumpiert wurde. Sehr hinterhältig. Beim Kernelupdate über das normale Systemupdate habe ich diesen Fehler nicht bemerkt, oder er wurde mir nicht angezeigt.

Jetzt jedenfalls, da das Update komplett durchlief, existiert auch für den neuen Kernel die initramfs, und die Startparameter sehen auch bis auf die Versionnummer identisch aus wie beim alten Kernel, und das System bootet endlich korrekt.

Wie das jetzt bei dem anderen Rechner ist, bei dem nur ein Kernel verfügbar ist, weil seit der Neuinstallation schlicht noch kein Kernelupdate durchgeführt wurde, muss ich diese Woche noch ergründen. Jetzt habe ich ja immerhin viele neue Erkenntnisse und Möglichkeiten, das zu untersuchen. VirtualBox ist dort jedenfalls ausgeschlossen, da es nicht installiert ist. Und ein Kernelupdate hat der Rechner wie gesagt auch nicht, also muss es irgendwas anderes sein. Bin gespannt.

Danke also bis hierhin!

 

[kieleich]

die initrd wird ja nicht beim bootvorgang irgendwann geladen sondern gleich zu anfang vom bootloader, die kernelparameter haben zu diesem zeitpunkt noch kein auswirkung. insofern etwas komisch das da jetzt diese fehlermeldung neu dazu gekommen ist nach der parameter änderung

das virtualbox da irgendwie rein gegrätsched hat kann sein. ich nutze Vbox lange nicht mehr, meine virtualisierung geht alles über Qemu KVM.

updatest du immer das komplette system oder irgendwie in teilen? oder wieso hat das vbox update gefehlt. teilupgrades werden oft nicht richtig unterstütz und führen zu problemen

das root=/dev kann man machen aber dann muss man sich sehr sicher sein mit dem gerätenamen der in dem beispiel ja von cryptdevice== gesetzt wird

UUID= hat den vorteil das jeder gerätename akzeptiert wird hauptsache es existiert überahupt. ob das dann /dev/mapper/luks-schlagmichtot ist oder ordinärres /dev/dm-123 ist dann egal

und fall mal ein gerät neu formatiert wird und die UUID deswegen ändert wird nicht eifnach so das falsche gemountet, daher eigentlich immer UUID= vorzuziehn

 

[ThommyDD]

Ich mache immer die Updates, die mir die Updateverwaltung anbietet. Das Problem war wohl, dass die Repositories nur das alte VirtualBox beinhalten. Ich habe mir jetzt die Oracle-Paketquelle eingetragen, damit das nicht mehr passiert. Trotzdem fürchte ich, dass sowas wieder passieren kann, weil ja der neue Kernel erstmal da sein muss, bevor VirtualBox ihn unterstützen kann. Die Anpassung wird also zwangsläufig danach erst erfolgen. Muss ich echt mal weiter beobachten. Immerhin erwischt es mich jetzt nicht wieder so kalt. Und ich habe heute gleich noch ein gesamtes Plattenimage gezogen, nur für alle Fälle.

Das Problem mit initrd war ja, das initrd weder vorhanden war noch aufgerufen wurde. Es fehlten zwei Sachen. Die Datei an sich, und das Grub-Skript für den neuen Kernel war unvollständig. Wobei ich das nicht verstehe, weil ja die Installation der Dateien sicher ein Vorgang ist und die Anpassung von Grub ein anderer. Warum beide Schritte unvollständig waren, verstehe ich nicht. Irgendwie komisch, was da passiert ist, ich kann es mir immer noch nicht ganz erklären.

Und dass die verschlüsselte Partition mit /dev/mapper statt UUID aufgerufen wurde, ist auch mysteriös. Denn das jetzt durchgelaufene Kernelupdate hat ja wieder wie beim alten die UUID-Methode gesetzt.