Talk:Dm-crypt/Encrypting an entire system
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)
Encrypted boot (GRUB): no need for separate partition?
+---------------+----------------+----------------+----------------+----------------+ |ESP partition: |Volume 1: |Volume 2: |Volume 3: |Volume 4: | | | | | | | |/boot/efi |boot |root |swap |home | | | | | | | | |/dev/store/boot |/dev/store/root |/dev/store/swap |/dev/store/home | |/dev/sdaX |----------------+----------------+----------------+----------------+ |unencrypted |/dev/sdaY encrypted using LVM on LUKS | +---------------+----------------+--------------------------------------------------+
It works perfectly fine, including the Dm-crypt/Device_encryption#With_a_keyfile_embedded_in_the_initramfs trick. The result is clearly a lot simpler and neater, and allows avoiding Dm-crypt/Encrypting_an_entire_system#Configuring_fstab_and_crypttab_2 altogether, again being able to unlock everything by entering the password only once.
Can anybody think of any disadvantages, or worse, security holes? Otherwise I'd like to update the current scenario with this method.
The only problem I can think of is that Dm-crypt/Specialties#mkinitcpio-chkcryptoboot needs the partition to be separate, but we can merge Dm-crypt/Encrypting_an_entire_system#Configuring_fstab_and_crypttab_2 there and leave a link from Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB) as a Tip.
- You don't even need a separate volume for /boot. It can perfectly reside on the root volume, and GRUB will be able to boot from it.
- --Elijah Master (talk) 18:03, 6 December 2017 (UTC)
Full disk encryption with LUKS (encrypted LVM with swap and root)
I wasnt able to find what I need on the wiki, but this guide got me there. I hope the arch wiki could summarize step by step as this guide does. https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/
- Wow, that's a thorough guide indeed. Nice to see someone reused the ASCII partition layout diagram (I think Kynikos sketched this LVM one:). It also links to our instructions in a number of places, which makes me wonder if the author keeps it updated in case links change. Anyhow, very thorough, yes. --Indigo (talk) 09:59, 6 May 2016 (UTC)
- I don't remember who originally sketched that particular diagram, but everything's published under GFDL :)
- To give an answer to Voukait, we don't keep step-by-step guides like that in this wiki, as they are too difficult to maintain because too many pages would duplicate content and should be continuously kept in sync.
- I think a good way of getting a first grasp on some topic is indeed to go and read "aggregated" information for a specific use case on some external sites/blogs, and then come to the ArchWiki to read more up-to-date information that can be more easily adapted to other scenarios.
- Anyway we should really find a place in this article where to list external links like that.
- — Kynikos (talk) 05:03, 7 May 2016 (UTC)
Rename volume group to be more consistent with device naming
I propose renaming 'MyVol' to 'volumegroup' (or something similar) to improve consistency with the device names (which are all lower case), and make the example more meaningful. —This unsigned comment is by Terry tibbles (talk) 08:13, 16 April 2018. Please sign your posts with ~~~~!
- I'm not against renaming it, but "volumegroup" is too generic. Also the use of uppercase letters gives a hint to the reader that using them is allowed. -- nl6720 (talk) 08:32, 16 April 2018 (UTC)
- I think it needs to change, as I've done this several times and still find it confusing. If you imagine that someone has several volume groups, it doesn't scale well (MyVol, MyVol1), and also the mix of capital and lower case letters is difficult to read. I think a system with 'vol_group-root_crypt' for encrypted devices and 'root' for the decrypted partition would be preferable. Terry tibbles (talk) 09:25, 18 April 2018 (UTC)
- 'vol_group' does not scale any better than 'MyVol'. Is there really a major difference between 'vol_group1' and 'MyVol1'? Also shouldn't the LVM names be distinguished from physical device names like sda1? One is virtual the other physical. What exactly is confusing about 'MyVol'? It's just a placeholder for what you name the volume group. Lastly, different examples use different names or pseudo-variables. Is there really a need to have the entire page consistent beyond each example? Most users will pick one example and the partitioning scheme is clearly defined at the beginning of each example. The names chosen seem trivial as they all represent the same concept of virtual groups and logical volumes. -- Wincraft71 (talk) 10:58, 19 April 2018 (UTC)
- I think more important than the spelling here is that 'MyVol' is misleading because it's supposed to be an example name for a volume group, not a volume, so it should be at least 'MyVolGroup', 'MyVGroup' or 'MyGroup'.
- Regarding the spelling though, I prefer the CamelCase version because then it's easier to tell group and volume apart in the /dev/mapper/volume-group path.
- -- Kynikos (talk) 15:57, 20 April 2018 (UTC)
Add notes to explain /etc/cryptroot layout (revision 517646)
I think these are needed because this process is already complicated, and this may not be obvious to a new user. It needs to be clear that /etc/crypttab is decrypted partitions and encrypted devices, and /etc/fstab is decrypted partitions and mount points. Terry tibbles (talk) 09:09, 18 April 2018 (UTC)
- (For reference, the original edit, and my undo)
- This article is only a collection of particular scenarios, general explanations should be made in the referenced articles; all the scenarios that use crypttab link to crypttab, which new users are supposed to have read before going back to the scenario, therefore I think it's better if you try to improve that section. -- Kynikos (talk) 14:24, 18 April 2018 (UTC)