Hi, I thought you may be interested in participating to Talk:Dm-crypt_with_LUKS#Splitting_sections_into_separate_pages :) -- Kynikos (talk) 02:56, 30 September 2013 (UTC)
- Oh, a new LUKS plan. Thanks for the heads up. I can't right now but will join in asap/24h. --Indigo (talk) 05:26, 30 September 2013 (UTC)
I am writing this as I frequently edit disk encryption wiki pages here and want to gain some input on upcoming news and hopefully help to minimize disjunct editing:
Systemd is evolving a lot. One recent change has been the new
systemd hook. It simplifies a lot of setups, but is not compatible with a number of older hooks. One of those is
encrypt. Now User:brain0 is thankfully working on a new hook
sd-encrypt to remedy that. While that has one big advantage of using systemd backend, i.e.
systemd-cryptsetup-generator, to setup the encrypted devices, it also is not compatible in the kernel command line options. So, these and the mkinitcpio configuration advice have to be changed to show the new options on various pages.
Now how do we handle this on the various wiki pages on disk encryption? Imo a reasonable way would be to add a respective alternative for the
mkinitcpio and bootloader sections of the disk encryption wiki pages. However, it would be good in my view to give a general advice on when and how to use the new hook. Likewise this should detail when the old encrypt should be used.
So, question (1): what should that general advice contain? E.g. which other hooks (a setup might need) are known not to be compatible with the
systemd and, hence,
sd-encrypt. Keyboard, keymap? (sd-vconsole I saw is going to be added). How about mdadm_udev, lvm and resume? Others?
Question (2): In my view it would be very preferable to have the general configuration advice in one place, so that the specific disk encryption pages do not have to go to lengths but can crosslink and just state the two alternatives where available. A good place for this should be Mkinitcpio, which can be referred to by the disk encryption pages. But the hooks are explained there very brief in a table. Other good options?
Question (3): I have not tried it, but I was wondering what the new option of having a
/etc/crypttab.initramfs entails. What is a usecase where one might want to use that? The usual way of crypttab being parsed during boot is not affected by the change to
sd-encrypt I reckon.