Difference between revisions of "Talk:Dm-crypt/Encrypting an entire system"
(→LVM on LUKS kernel parameters: re and close)
m (Kynikos moved page Talk:Dm-crypt/Encrypting an Entire System to Talk:Dm-crypt/Encrypting an entire system: comply with Help:Style#Title)
Revision as of 15:38, 6 May 2014
LVM on LUKS on LVM
IMO it would be interesting to restore it as a stub section here, like Dm-crypt/Encrypting_an_Entire_System#LUKS_on_software_RAID, waiting for somebody to fill it up, what do you think?
I've also found a forum thread: .
- It sure is an interesting use case, but I am hesitant. The main reason is that it has to be certain that udev device discovery (be it with encrypt or sd-encrypt) is rock solid longterm for such a setup, see e.g.  for related problems. The edits you refer to originate from before that and also before systemd. Therefore I think it would be sensible to have developer input on viability/route for such a sandwich.
- I am biased though, I generally prefer encryption as the first mapper. One reason is that it is very easy to seriously wreck a LUKS blockdevice with a single resize statement, if lvm hovers over it.
- A final thought on LVM: crypttab offers vanilla flexibility for multiple disks. It would be interesting to know, if someone runs an Arch setup with multiple non-root fully encrypted disks, mounted via crypttab/fstab and joined to a single VG. That might be a worthwhile alternative extension for the shorter Dm-crypt/Encrypting_a_Non-Root_File_System ?
- edit: before I forget - a variation of above alternative extension on the non-root page instead may be not to use LVM but have multiple non-root fully encrypted disks and use a btrfs raid1 inside it. Users experiences with that might also be interesting for others.
- Plenty of food. Looking forward to read/learn other opinions/experiences. --Indigo (talk) 22:13, 18 February 2014 (UTC)
LUKS on LVM /tmp example
I don't think the example config for /tmp is correct. It uses tmpfs, which completely bypasses the physical disks (other than swap), making the whole endeavor pointless. The proper solution seems to be to use the 'tmp' option in /etc/crypttab--I just set this up, and it seems to be working. It automatically creates a new ext2 filesystem with a random key on each boot. I'd update the article, but the crypttab syntax it uses doesn't even match mine, and I don't know how to translate to the new syntax. TravisE (talk) 10:27, 11 March 2014 (UTC)
- You probably use in crypttab "tmp=ext2" as option? I'd say you are right anyway (and the example still works but wastes the reserved lv diskspace). Feel free to edit right away if you clarified or post the settings you use here and we adapt them. --Indigo (talk) 20:06, 11 March 2014 (UTC)
- I updated syntax: 
- I still left the lv for it. Question to answer before removing it would be where /tmp swaps to, if required. Do you know that?
- --Indigo (talk) 22:45, 25 March 2014 (UTC)
Clarifying "LUKS on LVM"
- In "LUKS on LVM", the following commands are used to "Randomise /dev/sda2":
cryptsetup -d /dev/random -c aes-xts-plain64 -s 512 create lvm /dev/sda2 dd if=/dev/urandom of=/dev/mapper/lvm cryptsetup remove lvm
What's the point of this? Why not just
dd if=/dev/urandom of=/dev/sda2?
- In /etc/crypttab, the following line is used for swap:
swap /dev/lvm/swap SWAP -c aes-xts-plain64 -s 512
What does specifying "SWAP" as keyfile do? Couldn't find documentation on this.
- And why should the keyfile for home be 256 bytes if the key size is 512 bits? --Bypeoplelikeyou (talk) 21:37, 24 March 2014 (UTC)
- The section LVM_on_LUKS you refer to still needs care to bring it up-to-date and into line with the structure followed for the scenarios.
- To your questions:
- The use of /dev/urandom is unnecessary. The quoted approach was probably chosen back then to speed up the randomising of the device, but then using /dev/urandom is not beneficial. /dev/zero should be used. We want to crosslink such instructions: 
- Good catch. Again this stems from history. When that section was written, crypttab still had an option to specify a passphrase (and "SWAP" was used as the example one). The use of passphrases was later deprecated (in 2012) and this line was not updated. IF you use it like that now, cryptsetup parsing will prompt for a (new) passphrase (for swap) on boot, i.e. it would boot with crypted swap after you provide a/any pass. In any case I updated it: 
- In your last question, you mix up the options "--key-size" (for the cipher) and "--keyfile-size" (for the keyfile). We have that covered in Dm-crypt/Device_Encryption#Encryption_options_with_dm-crypt
- --Indigo (talk) 22:36, 25 March 2014 (UTC)
LVM on LUKS
On the page it says “This method will not allow you to span the logical volumes over multiple disk, even in the future. For a solution that allows to do so, see #LUKS on LVM”. This is wrong IMHO, you can create another LUKS container and use that as a second LVM physical volume. --Dingens (talk) 13:25, 23 April 2014 (UTC)
- Your quote speaks of "spanning the logical volumes over multiple disks", i.e. extending the vg/lv created later by virtue of LVM to the next device. What you suggest is ok, but it can be done to any scenario on the page and not for the lv-root created in the scenario. For example, you have a small disk that runs full, add another disk and want to extend the encrypted lv-root to the new disk. With "#LUKS on LVM" you can theoretically do that, with the other scenarios not (single cryptdevice= option).
- --Indigo (talk) 18:52, 23 April 2014 (UTC)
LVM on LUKS kernel parameters
The LVM on LUKS sections correctly indicates that the bootloader needs to supply the following kernel parameter:
where MyStorage is the name of the volume group. It then says "See Dm-crypt/System_Configuration#Boot_loader for details.". The linked page says to supply the following different kernel parameter:
where "dmname is the device-mapper name given to the device after decryption, which will be available as /dev/mapper/dmname"
This doesn't work if you're using LVM on LUKS, since the names in /dev/mapper will be of the form volume_group-volume. I discovered this the hard way. Perhaps the Dm-crypt/System_Configuration#Boot_loader page could be modified to reflect that the device-mapper name isn't always right?
- Let's better say the device mapper is always right, but mkinitcpio parses a different format. So yes, I am with you. It is contradictionary. I did two edits to clarify it on the configuration subpage: . We have a couple more of these in LUKS on LVM; I'm closing this point. If you think something is wrong or could be improved in wording, feel free to edit right away, open this item again or a new one.
- --Indigo (talk) 18:07, 1 May 2014 (UTC)