cryptsetup: Don't try to tear down LUKS devices with `rd.luks` during shutdown

[cgwalters]

systemd version the issue has been seen with

257

Used distribution

CentOS Stream 10

Linux kernel version used

6.12.0-124.el10.x86_64

CPU architectures issue was seen on

x86_64

Component

systemd-cryptsetup

Expected behaviour you didn't see

See ostreedev/ostree#3503

Basically right now systemd-cryptsetup-generator has support for x-initrd.attach in /etc/crypttab to say not to unmount the LUKS device backing / during shutdown.

But installation tools need to know to add that. Instead since we already need to have rd.luks.uuid= or so on the kernel cmdline, the generator should automatically imply the same effect for the mount units it generates, around here

systemd/src/cryptsetup/cryptsetup-generator.c

Line 391 in c4d9f9c

if (!attach_in_initrd(name, options))

(basically if there's a karg present too).

Unexpected behaviour you saw

This is especially important for soft reboots, where today having this Conflicts=umount.target causes transaction conflicts and a total failure to soft reboot.

Steps to reproduce the problem

Install CentOS Stream 10 with Anaconda + LUKS. (Or Fedora, or...)

Additional program output to the terminal or log subsystem illustrating the issue

[cgwalters]

cc @msekletar

[bluca]

But installation tools need to know to add that. Instead since we already need to have rd.luks.uuid= or so on the kernel cmdline, the generator should automatically imply the same effect for the mount units it generates, around here

Are you sure about that? I don't have rd.luks.uuid here on a Debian install, I think that's just optional?

I just had the debian scripts updated to add x-initrd.attach. Why is it a problem for installers to add that option?

[cgwalters]

Are you sure about that? I don't have rd.luks.uuid here on a Debian install, I think that's just optional?

Does the /etc/fstab end up in the initramfs in that case?

I just had the debian scripts updated to add x-initrd.attach. Why is it a problem for installers to add that option?

It's not at all a problem and I already have a bug filed against Anaconda to do it. However, it is really useful to also fix this in systemd because I think this is a pretty small task and it means systems upgraded in place automatically get the fix.

(Of course an OS/distro could ship a script which auto-updates /etc/crypttab, but it's just a bit ugly)

[bluca]

not fstab, but I do have crypttab in the initrd via an addon

[cgwalters]

Right sorry I meant /etc/crypttab of course.

I just had the debian scripts updated to add x-initrd.attach.

Can you link this for posterity?

---

I guess in theory for the case of "/etc/crypttab in initramfs" the cryptsetup generator could pass the state from the initramfs to the real root that that specific device was already mounted in the initramfs and should hence gain the same effect as x-initrd.attach.

[bluca]

Can you link this for posterity?

https://salsa.debian.org/installer-team/partman-crypto/-/commit/9f50fd3fadc7f8ba22fc91e3f2a6519d79f8d37b

[yuwata]

As a workaround, try to set x-initrd.attach in luks.options=.

[poettering]

i don't grok why this would be necessary? if tools can synthesize rd.luks= they can also synthesize luks.options=x-initrd.attach? that sounds like enough?