wird /etc/crypttab noch verwendet?

[reox]

Ich hab in meinem Laptop zwei Platten (mSATA und SATA) und beide sind mit Luks verschlüsselt. Nun sind auf den verschlüsselten Volumes einfach LVMs drauf. Und zwar beide PVs in der selben VG und dann mehrere LVMs für root, home, swap, ...
Da die mSATA SSD für das / lvm gebraucht wird, wird sie über den cryptroot hook im initramfs entschlüsselt. Für die andere habe ich einen eintrag in /etc/crypttab gemacht allerdings erhalte ich dann beim erstellen vom initram folgende warnings:

Code: Alles auswählen

cryptsetup: WARNING: Missing line in /etc/crypttab for cryptroot
cryptsetup: WARNING: Missing line in /etc/crypttab for cryptdata

Die /etc/crypttab schaut so aus (mit der echten UID natürlich ):

Code: Alles auswählen

cryptdata UUID=00000000-0000-0000-0000-000000000000 none luks

Was ist da jetzt genau das Problem? Checkt das initram eh schon ab, dass man die partition entschlüsseln muss und /etc/crypttab ist hinfällig? Oder soll ich das einfach so lassen und die Warnings ignorieren?

[wanne]

Was ist da jetzt genau das Problem? Checkt das initram eh schon ab, dass man die partition entschlüsseln muss und /etc/crypttab ist hinfällig?

Prinzipiell ja. Nur wird beim erstellen der initrd typischerweeise einfach die /etc/crypttab rüberkopiert (Weiß nicht wie debian das per installer macht. Aber wenn ich das von Hand mache ist das so.). Entsprechend ist beim nächsten Kernelupdate das system unbootbar, wenn da der Eintrag in der /etc/crypttab fehlt.
Sonst sieht die /etc/crypttab (zumindest für ein nicht systemd-System) korrekt aus.

(mit der echten UID natürlich

Werde nie Verstehen, warum leute zwar kein problem damit haben ihre mails in die ganze Welt zu possaunen, aber unbedingt Zuallszahlen geheim halten müssen...

[reox]

Was ist da jetzt genau das Problem? Checkt das initram eh schon ab, dass man die partition entschlüsseln muss und /etc/crypttab ist hinfällig?

Prinzipiell ja. Nur wird beim erstellen der initrd typischerweeise einfach die /etc/crypttab rüberkopiert (Weiß nicht wie debian das per installer macht. Aber wenn ich das von Hand mache ist das so.). Entsprechend ist beim nächsten Kernelupdate das system unbootbar, wenn da der Eintrag in der /etc/crypttab fehlt.

Naja das cryptroot wird ja über diesen hook entschlüsselt, also das macht das initram ja automatisch. ich glaube ich muss mich in /etc/crypttab nur um die entschlüsselung von anderen volumes kümmern?

Sonst sieht die /etc/crypttab (zumindest für ein nicht systemd-System) korrekt aus.

mh es ist debian jessie, also systemd ist schon drauf was ist dann da anders?

(mit der echten UID natürlich

Werde nie Verstehen, warum leute zwar kein problem damit haben ihre mails in die ganze Welt zu possaunen, aber unbedingt Zuallszahlen geheim halten müssen...

*g* ich hab die zeile nicht von meinem laptop kopiert und da waren nur 0er drin

[wanne]

Naja das cryptroot wird ja über diesen hook entschlüsselt, also das macht das initram ja automatisch

Wie gesagt klassicheer weise sagt der Hook halt nur, dass er die crypttab in die initrd kopieren soll. Zuerstmal ist dann die alte crypttab da drin entsprechend kannst du am Original ändern was du willst. Aber sobald das nächste mal update-initramfs -u aufgerufen wird, ist dann halt aus, weil dann die neue crypttab in die initrd kopiert wird, und der Eintrag nicht mehr da ist. Passieren tut das typischerweise halt beim kernelupdate.

Ist für dich aber erstmal irrelevant. Unter Systemd läuft das anders (Ohne gewähr – mit system kenne ich mich nicht so gut aus):
Die /etc/crypttab wird geparsed und die enschlüsselung von / als Kernelparameter in den Grub angefügt.
Den bekommt dann wieder Systemd vom kernel mitgeteilt und entschlüsselt das dann.
Ensprechend müsste auch da beim kernelupdate der boot kaputt gehen. Allerdings kannst du einfach gucken, was da jetzt als Parameter dransteht und das hart als Parameter angeben.