It turns out that the systemd-generators in the initramfs run very early, even before device files for block devices are created in /dev/. So far, I couldn't come up with a way for the generator to figure out the UUID of the ROOT partition under these circumstances. Any ideas would be very welcome.

If we decide that it's not feasible to implement this generator, we could instead implement a systemd service that runs in the initramfs or even during late user space boot. That service would determines the UUID of the ROOT partition and add rd.luks.uuid=$uuid to the kernel cmdline parameters in grub.cfg. It would bring the same benefits as the generator: the user would not need to specify the rd.luks parameter in their Ignition config, and we would ensure that the cmdline parameter is not yet present during the first boot.

About the timing; generators may run multiple times. We could also have a look at how the systemd gpt auto generator manages to "wait" for the device.

We could also have a look at how the systemd gpt auto generator manages to "wait" for the device.

I might be reading the code wrong, but I think the systemd-gpt-auto-generator does not itself wait for device files to appear. Instead, it generates a cryptsetup service that waits for a device file to appear, which is later created by udev (see here). We could adapt that strategy by adding a systemd service that decrypts the ROOT partition once it's available, but the whole idea was to just piggy-back on the cryptsetup-generator rather than writing our own decryption service.

About the timing; generators may run multiple times.

What did you have in mind here? One option that might work (not sure whether that's what you thought of) is to trigger re-running of generators by adding a service that runs systemctl daemon-reload. If we do this after udev, the generator I wrote would probably work because all the device files are present. However, I'm not sure running systemctl daemon-reload is a good idea, since this is a global operation and might have unintended side-effects.

Thanks, thinking about this I guess we can try to define a helper service that runs the logic to invoke the generator. Since we know what service the generator will write out, we can explicitly start this generated service with systemctl start. It's best to avoid the daemon-reload and we can do so by calling the generator with /etc/systemd/system/ as directory to write to.

Thanks, thinking about this I guess we can try to define a helper service that runs the logic to invoke the generator. Since we know what service the generator will write out, we can explicitly start this generated service with systemctl start. It's best to avoid the daemon-reload and we can do so by calling the generator with /etc/systemd/system/ as directory to write to.

Sounds good 👍 I implemented this approach. Let me know what you think.

I added the service under 31decrypt-root/ but I'm uncertain whether 31 is the most appropriate number here because I'm uncertain about what the logic behind the names of the various dracut modules in dracut/ is. Let me know if a different number prefix would be more fitting.

I added the service under 31decrypt-root/ but I'm uncertain whether 31 is the most appropriate number here because I'm uncertain about what the logic behind the names of the various dracut modules in dracut/ is. Let me know if a different number prefix would be more fitting.

Hello @simoncampion, the only usable systemd command for this scenario is systemd-analyze plot. I used it succesfully during my kmod static nodes PR, to be able to see properly the systemd execution tree during initrd and after switch root.

Should look like this and is very helpful to see the order

@ader1990 Thanks for the hint! That's a neat command.