Talk:Dm-crypt/System configuration

"2.3 Using sd-encrypt hook" very confusing

I stumbled into the topics sd-encrypt and systemd-based init system through the section in this article, because i want to unlock two LUKS devices which together contain the root fs. The sd-encrypt section is very confusing, since it's basically just a reference and a bad starting point to learn about systemd init systems and sd-encrypt. I think the section would be more helpful if it would start with a few basic system configurations, ie. some examples. With just the reference it is very hard to tell which parameters/config files are actually needed, and how they complement or replace each other. Unfortunately as of right now i don't know enough to add examples. Cheers, Clonejo (talk) 15:51, 16 May 2021 (UTC)

tried to simplify, removing only things that are already mentioned in two other places at least on the same page, here's the rollback https://wiki.archlinux.org/index.php?title=Dm-crypt/System_configuration&curid=17199&diff=693328&oldid=693327 and that have nothing to do with mouting root with sd-encrypt. Gcb (talk) 10:32, 29 August 2021 (UTC)

Clarification on how /etc/crypttab.intiramfs works

I authored the revision that has been recently reverted here: https://wiki.archlinux.org/index.php?title=Dm-crypt/System_configuration&curid=17199&diff=760284&oldid=760001

I do not thing the past (or now, current) explanation is wrong. However, I do think the wording can be confusing. When the page says "If the file /etc/crypttab.initramfs exists, it will be added to the initramfs as /etc/crypttab", what makes me think is that if /etc/crypttab.initramfs does not exist, then /etc/crypttab will be copied to the initramfs instead. In other words: I think with the current wording, the /etc/crypttab.initramfs file can be perceived as an override to /etc/crypttab for initramfs, which is not.

Maybe I'm the only person that got confused by this, and perhaps my now reverted edit was not extremely clear, so I just wanted to expand on my motivation a little bit here. --Roobre (talk) 14:52, 13 December 2022 (UTC)

Ok, I can see how that confusion could happen. Hopefully Special:Diff/760611 helps. -- nl6720 (talk) 14:37, 14 December 2022 (UTC)

Reordering

This article is fairly confusing in its organisation. Jotting down a few ideas for a reordering, for reference as I don't have time to modify the article right now.

quick draft

Current structure	Suggested one
Unlocking in early userspace mkinitcpio Kernel parameters root resume Using encrypt hook Using systemd-cryptsetup-generator Unlocking in late userspace Crypttab Troubleshooting	Initramfs mkinitcpio dracut etc.. Using crypttab and crypttab.initramfs Using Kernel parameters root resume Using encrypt hook Using sd-encrypt hook Troubleshooting

Considering:

• Dm-crypt/Encrypting a non-root file system already exists and, despite the name, also deals with decrypting non-root file systems
• Dm-crypt/System configuration deals with decrypting both root and non root, both in early and late userspace.

I think one page should deal with decrypting root, and the other with other non-root filesystems, or alternatively, one page with decrypting in early userspace and the other in late userspace to avoid overlaps. Or maybe just delete the decrypting part of Dm-crypt/Encrypting a non-root file system and use the draft above.

It should also be made prominently clear from the beginning that using GPT automounting is a very simple way to make all of this beefy article completely obsolete for most setups.

-- Cvlc (talk) 01:30, 14 January 2023 (UTC)

I'm against changing the structure like that. The current structure states that there are two main ways to automatically unlock encrypted devices: early userspace and late userspace, IMHO it's important to have this distinction made clear. While dm-crypt/System configuration#mkinitcpio and dm-crypt/System configuration#Kernel parameters may not have the best order or structure, I don't see a better way to organize them.

As for dm-crypt/Encrypting a non-root file system, there is very little about unlocking there. The only change I would make is replacing the two links in dm-crypt/Encrypting a non-root file system#At boot time with dm-crypt/System configuration#Unlocking in late userspace.

-- nl6720 (talk) 07:23, 14 January 2023 (UTC)

I understand, however it is equally true that there are two main ways to decrypt devices, using kernel parameters, or using crypttab(.initramfs). It's the usual A(1,2)B(1,2) vs 1(A,B)2,(A,B) problem. The thing is, I think we should look at it from the point of view of someone coming from the installation guide, who just clicked on "system encryption" in : "If you want to create any stacked block devices for LVM, system encryption or RAID, do it now". The wiki needs to quickly point to an overview of how this can be achieved, rather than just reproduce info from man pages.

My problem with leaving it as it is, is that encryption is actually pretty straightforward, and the wiki actually makes it look a lot more complicated than it is. For example, the possible use of crypttab.initramfs, despite being arguably easier than that of kernel parameters (possible use of LABELs, visible layout if decrypting multiple devices, typos easier to spot) is hidden inside a tip in the middle of the page. Of course, this page is not the only culprit, and Dm-crypt/Device encryption also needs some love.

I also like the current structure as a theoretical overview, I just don't think it's as efficient when you just want to get things done.

-- Cvlc (talk) 11:25, 14 January 2023 (UTC)

This is Arch Linux, things don't get done around here. /s

The "two main ways to decrypt devices" are not always interchangeable. Things that must be unlocked in early userspace (root and swap when using hibernation) cannot be specified in /etc/crypttab. While unlocking things earlier than needed (e.g. unlocking /home) should work most of the time, it needlessly complicates things and could cause issues with more complex block device setups.

crypttab.initramfs is specific to mkinitcpio's sd-encrypt hook. AFAIK, dracut and booster don't support such a thing. The usual way to unlock devices in early userspace is kernel parameters, so that's the main thing we should stick to.

-- nl6720 (talk) 12:18, 14 January 2023 (UTC)

In that case Dm-crypt/System configuration#Using systemd-cryptsetup-generator is a little inaccurate, it says that systemd-cryptsetup-generator is invoked by the systemd dracut module and doesn't mention that crypttab.initramfs does not work with that. It's tricky because the sd-encrypt hook which has the crypttab.initramfs trick is installed by cryptsetup, but it doesn't look like it comes from upstream.

So it might indeed not be interchangeable with kernel parameters, when using Dracut, but it definitely is when using mkinitcpio. Dracut is not the default though, so I think a warning regarding Dracut would be enough, and does not change the logic above.

If we keep the current layout then, maybe a short intro explaining what needs to be unlocked early / late can help.

-- Cvlc (talk) 15:11, 14 January 2023 (UTC)

Indeed I just stumbled upon this particularity with crypttab.initramfs not working on dracut as implied here, finally found out what was going on and came here to correct it.

I am still experimenting, but would you not be able to simply include /etc/crypttab in dracut? Perhaps that would be a decent suggestion to place here as replacement.

gonna go try that now and wait for feedback here

--Deduct1069 (talk) 14:49, 21 January 2023 (UTC)

I suggest to move the dracut crosslink/reference into the tip. I can see how its current mention along with the default mkinitcpio is confusing. Without doubt dracut has crypto-related options/modules that are not covered by our default. Yet, it can't be this article to describe them. Dracut/Dracut#Dracut modules should probably gain more flesh to elaborate what the systemd-generator implements regarding dracut.modules(7) § Initramfs_Functions ..

crypttab.initramfs is hooked into cryptsetup, because that package owns crypttab and the split is to provide choice what to unlock in early boot. I'm not sure a lot of users need/want to unlock much more than root at this stage. Perhaps it would be best to disentangle the basic rd.* parameters to unlock root and move the whole tip down towards Dm-crypt/System configuration#rd.luks.options (ordering this under it). This way it may be easier to get a bootable system with the generator. Users installing are unlikely to have multiple devices in crypttab already and if they do, it is covered as is just a little below.?

--Indigo (talk) 06:51, 22 January 2023 (UTC)

I guess the question is: should other initramfs generators besides mkinitcpio be documented in this page? The expansion template at the top makes me think they should, but currently there's no dracut or Booster section there. -- nl6720 (talk) 15:34, 23 January 2023 (UTC)

Valid point. Although the reordering suggested above allows for keeping other generators while specifying, in the first part, that dracut and others have to use the kernel parameters method, while standard setups with mkinitcpio can choose one method or the other. keeps all the info but avoids the clutter.

-- Cvlc (talk) 17:52, 23 January 2023 (UTC)

All methods use kernel parameters. mkinitcpio gained systemd support very early on, offering it an alternative. Of course it is useful to document further alternatives that were gained since, but why start it in this article, which is for core repo Arch? Take Booster, another alternative nl6720 rightly mentions. Booster#Enable encryption explains very efficiently how to use it to boot an encrypted root. It is definetely due to crosslink it (both directions), just as dracut - which still needs similar instructions. The good point is that (afaik) systemd used the rd. nomenclatura from dracut anyway, so there should be no problem to crosslink the respective #Using systemd-cryptsetup-generator explanation, if needed.

--Indigo (talk) 21:51, 23 January 2023 (UTC)

I've looked at Booster#Enable encryption again and think it makes no sense to mention it in this section, as it implements a dedicated subset of rd. kernel and LUKS crypto parameters. It could be crosslinked alongside dracut in the article introduction (as available alternatives to primarily covered mkinitcpio), once that is added.

--Indigo (talk) 21:20, 1 February 2023 (UTC)

Reading this section again, I think we could gain clarity by adding a subsection for crypttab.initramfs before 1.2.4.4 crypttab.options, and moving the info from the Tip into it, just referencing it from the intro.

Question: The warning states "To activate all devices in /etc/crypttab do not specify any luks.* parameters and use rd.luks.*.". Is this correct? luks.crypttab= defaults to Yes.

--Indigo (talk) 22:58, 1 February 2023 (UTC)

The warning is correct. systemd-cryptsetup-generator(8) mentions it too: "If /etc/crypttab exists, only those UUIDs specified on the kernel command line will be activated in the initrd or the real root." -- nl6720 (talk) 10:02, 2 February 2023 (UTC)

Ok, thanks. Below I take the subsection intro and poke it a little. If that makes sense along above talk, I'd take a shuffle at the tip/note/warning next (dracut mention in the tip). --Indigo (talk) 23:39, 2 February 2023 (UTC)

I think the current first sentence is more correct than the one in the draft. systemd-cryptsetup-generator(8) doesn't unlock anything itself, it generates systemd-cryptsetup@.service(8) services that do. -- nl6720 (talk) 10:01, 6 February 2023 (UTC)

Fair enough, but "that -> to" can fix that. --Indigo (talk) 21:30, 7 February 2023 (UTC)

I close the draft snippet, frankly I don't find the time to expand it currently and don't want it to block others to contribute improvements. --Indigo (talk) 07:41, 16 April 2023 (UTC)

Description to mount at boot missing something

I just tried to follow the instructions for mounting at boot (2.1.1) yesterday and I was not able to successfully complete this task using the descriptions provided here. I think there are two problems here:

1. The instructions are not very well structured. I had the use case to mount my "home" partition, which is a second drive internally. So I didn't had deal with removable drives. But the documentation in 2.1.1 seemed to be jumping the use-cases back and forth.
2. There is definitely something missing. The systemd-cryptsetup@name.service is mentioned, but there is no hint how this would get used. I had to dig StackExchange and find this post to actually set up my fstab correctly and add x-systemd.automount,x-systemd.requires=systemd-cryptsetup@name.service to the mount options.

I would like to improve the article based on my experience, especially better structuring it for the different use cases (internal drives, removable drives) and also add the necessary systemd-dependency in fstab.

Any comments?

--Moabeat (talk) 08:24, 3 September 2023 (UTC)

The systemd dependencies should be handled correctly without any user intervention (if the crypttab and fstab are correct). The generated systemd services are started automatically and the .mount unit for a fstab entry is ordered after the relevant .device unit that appears when the systemd-cryptsetup@name.service opens the encrypted partition. — Lahwaacz (talk) 10:43, 3 September 2023 (UTC)

Thanks for the quick response. I revisited this now once more and you are absolutely right. I think what caused the issue was, that I didn't have the "defaults" options in my fstab for my home partition. For some reason this created an "home.automount" unit, which was triggered before the mapper became available and broke the dependency chain. Maybe worth a troubleshooting paragraph? --Moabeat (talk) 12:43, 3 September 2023 (UTC)

I don't think that systemd does anything special if the defaults is present or missing - it is just a set of options that are applied when mounting. Also home.automount should not be created unless you have the x-systemd.automount option. Without any x-systemd.* option there would be only home.mount. — Lahwaacz (talk) 13:03, 3 September 2023 (UTC)

I tried to reproduce this again, after it works properly now. I was not able to. Unfortunately I cannot trace back what was the issue my home didn't get automounted. I even did the same procedure on a second machine in the meantime the same issue didn't show up again. Moabeat (talk) 03:42, 22 September 2023 (UTC)