@NickCao have you confirmed this doesn't break LUKS? I believe that's the reason we had to disable that previously; it was causing LUKS devices to disappear between stage 1 and stage 2. In particular, this affects file systems that aren't mounted in stage 1, but are LUKS devices decrypted in stage 1.

The upstream issue is fixed and shipped, not sure about the luks part, is there a nixos test for that? (I'm a bit occupied these days and cannot test it myself)

@NickCao Ok, the issue that I remember having still persists. I thought that systemd issue was related to it, but I suppose it wasn't if they think that systemd issue is fixed.

Essentially, if you define a LUKS device with boot.initrd.luks.devices, but you don't have any stage 1 file systems on it, then enabling this service in stage 1 will cause udev to remove its SYSTEMD_READY tag, and it won't get picked up again in stage 2. The result is that the file system being mounted in stage 2 cannot find the device and fails.

@dasJ Do you remember what specific issue you ran up against with this service? IIRC it was different than mine.

LVM devices on cryptsetup utterly broken and udev not finding them iirc

Despite still not knowing how to fix the LUKS issue, I've make a nixos test to reproduce it: https://gist.github.com/NickCao/4fa2f532a3ec71ba9a8ff9e3ef9ef1e4

Looks like the device mapper devices are not missing, just udev deciding that they are not ready for prime time, which should have been fixed at the end of systemd/systemd#12953, which has landed in systemd 251.7, but the issue still persists.

I've found the fix to the problem: https://git.kernel.org/pub/scm/boot/dracut/dracut.git/tree/modules.d/90dm/11-dm.rules
dracut has been shipping this custom udev rule marking dm devices as db_persist, so that they survive the db cleanup.

@ElvishJerricco @dasJ are you two still interested in this?

Do we have a nixos test that covers this?

Despite still not knowing how to fix the LUKS issue, I've make a nixos test to reproduce it: https://gist.github.com/NickCao/4fa2f532a3ec71ba9a8ff9e3ef9ef1e4

I could adapt this to a nixos test if wanted.

That would be good to have, yea.

@ofborg test systemd-initrd-luks-password

The failure on aarch64 seems unrelated?

Yea, looks like it's had the same failure on hydra for a while now.

@ofborg test installer.luksroot

Just want to run this to make sure that udev rule isn't negatively messing with the regular initrd.