Arch Linux

lvmetad takes care of LV activation as devices appear. If that doesn't work, then you're probably running into one of many LVM bugs, e.g.  FS#41833  or  FS#37346 .

lvmetad doesn't activate any logical volumes until all of the physical volumes in the volume group are online.

So your suggestion is to try and forcibly activate LVs on a device before all the backing devices might be known? How does that work? Isn't this just asking for problems?

No, only activate LVs where they are entirely contained within the available PVs. This fact is reflected in the "health" attribute of the LV which can be queried prior to activation.

The specific scenario I was implementing was to handle early boot with the root filesystem on a LV contained within a VG comprised of multiple PVs on encrypted disks. The boot hooks are able to unlock the disk containing the required LV, allowing lvmetad to process the PV. Early boot has no need to unlock anything else. The LV is wholly contained and, as reflected by the health attribute, safe and can be activated without issue by "lvchange", which is what the patch does.

When the system boots, the remaining PV is unlocked via /etc/crypttab during the main systemd startup sequence. When the remaining PV comes online, the remaining LVs auto activate.

For a complex setup like this, you're better off using systemd in your initramfs. I think your patch is far too large of a hammer to be acceptable.

I just spent the last hour trawling information on systemd in initramfs but there isn't much that I can find. Yes I tried the wiki and asked my friend. I've read the wiki page and see the references to it but I can't see any info about actually doing it. For example, I am missing the mentioned hooks like sd-encrypt... can you give me any pointers...?

Seems pretty weird that you'd be missing that hook:

$ pkgfile /usr/lib/initcpio/install/sd-encrypt
core/cryptsetup

I expected to find it in /usr/lib/initcpio/hooks. I do have it in /usr/lib/initcpio/install.

Anyway, yes. using systemd would appear to be more flexible and I have it working that way now. I didn't originally use systemd because it isn't really documented that way in the wiki, but I guess it's new ground. Not needing to pass crypto parameters as kernel boot options is also nice.

Using systemd allows all PVs to be decrypted, thereby removing the issue but it does require that the keys for the other PVs are exposed to the early boot layer. That wasn't necessary before.

However... I found the systemd crypto tool lacking because it doesn't support the full range of options that "cryptsetup" does. I had to write my own unit to overcome that. Unforutnately the sd-encrypt hook doesn't include "cryptsetup" so I had to add it to BINARIES. Would it be possible for sd-encrypt to include cryptsetup so that the full range of options can be used?

I would still like to be able to do this without over-exposing keys. So, not wanting to be defeated, I wanted to write a unit that would basically do what my patch did so that the root LV could be unlocked when its PV comes online but I cannot work out what units to make it a dependency of. I am looking for a target that is activated when a PV comes on line because that's the event that should trigger the manual activation of the LV. Would you know what I should hook this into?

You don't mention any specific limitations in systemd's cryptsetup tool, so it's hard for me to know what advice to give you. Could you share those details?

Oh sorry, I'm using detached LUKS headers and key files. The cryptsetup "--header" option is not supported by "systemd-cryptsetup" and neither, by association, is it supported in "/etc/crypttab".

Seems to me like the logical thing to do is to, then, add support to /etc/crypttab for this.

That would be for upstream systemd to do though, right?

As far as I understand it, systemd runs "systemd-cryptsetup-generator" which parses /etc/cryptab and writes unit files that use "systemd-cryptsetup" to open crypt devices. Because "systemd-cryptsetup" doesn't have the capability to handle most of the "cryptsetup" options, neither does /etc/crypttab.

I would think adding cryptsetup to the Arch hook would be trivial and would make the main cryptsetup interface accessible during boot, just like it is without systemd. This would allow people to cater for use-cases supported by cryptsetup but not by systemd. Right now, you can do things with the "encrypt" hook that you cannot do with the "sd-encrypt" hook.

I've done that myself as I have explained so it isn't really a burning issue for me because I have configured my way around the problem, but it would be nice if the "sd-encrypt" hook provided the same tools as the "encrypt" hook.


Do you have any thoughts on my last comment, about getting a unit to trigger on a LVM physical volume being activated? I can't work that one out at all!

btw, found this: https://bugs.freedesktop.org/show_bug.cgi?id=66396 RFE: implement --header option in systemd-cryptsetup/crypttab

> Do you have any thoughts on my last comment, about getting a unit to trigger on a LVM physical volume being activated? I can't work that one out at all!
You'd need to create device units for the PVs by tagging them with 'systemd'.

Is this still a problem? systemd 219 supports the --header option.

Hi, sorry for taking so long to respond to you but work's taken me away from this specific issue.

Systemd 219 did indeed introduce the --header option so, for the immediate problem of being able to use detached headers in systemd, this issue is resolved.

I am not in a position right now to rebuild without my work-arounds in place so I can't be 100% certain that /etc/crypttab correctly supports detached headers now. However, having just taken a quick look, I see no reason why that would not be the case.