| 18 Apr 2026 |
 sss | maybe some better way exist to mount key beofre decryption and unmount after ? | 01:20:24 |
 hexa | post open is probably wants/after cryptsetup.target | 01:20:33 |
| sss | different keys for different devices | 01:20:38 |
| hexa | pre open could be wantedBy cryptsetup-pre.target, before cryptsetup.target | 01:21:08 |
| sss | ok, but what about different code for pre/post per device ? | 01:21:53 |
| hexa | Redacted or Malformed Event | 01:22:08 |
| hexa | well they're going to be two systemd units | 01:22:32 |
| sss | devices you mean ? | 01:22:49 |
| hexa | you can use the script attribute to port the script | 01:22:53 |
| hexa | ah, these were per device before | 01:23:06 |
| hexa | what are your hooks ding? | 01:23:16 |
| sss | mounting external devices with keys | 01:23:46 |
| sss | few devices | 01:23:55 |
 ElvishJerricco | The thing most strictly similar to postOpenCommands is just a service ordered with after = [ "systemd-cryptsetup@foo.service" ]; and before = [ "systemd-hibernate-resume.service" ];. If that seems obscure to you, that's because it is, and that's because scripted initrd was the one doing it weirdly before :P
The orderings that make the most sense depend on what you're actually trying to do
| 01:24:16 |
| sss | ok, so each device does have their own service ? | 01:25:13 |
| ElvishJerricco | For this purpose specifically, I could tell you how to craft a systemd service that does this nicely, but systemd actually already has a feature that does that automatically
boot.initrd.luks.keyFile = "/foo:UUID=asdf";`
This means that a drive with UUID asdf will have a key file at the /foo path in the contained file system
| 01:26:29 |
| ElvishJerricco | * For this purpose specifically, I could tell you how to craft a systemd service that does this nicely, but systemd actually already has a feature that does that automatically
boot.initrd.luks.devices.<name>.keyFile = "/foo:UUID=asdf";`
This means that a drive with UUID asdf will have a key file at the /foo path in the contained file system
| 01:26:44 |
| sss | interesting, thx for info | 01:27:16 |
| ElvishJerricco | that said, this makes me suspicious: Are these actually for your root fs? Or some extra file system? | 01:27:22 |
| ElvishJerricco | If the latter, don't do it in initrd at all | 01:27:26 |
| sss | it's partitions for lvm which contains root | 01:28:07 |
| sss | sounds weird, but it's legacy | 01:28:27 |
| sss | from even before nixos ) | 01:28:36 |
| ElvishJerricco | so like, you have drive A with a keyfile on it, drive A is unencrypted, and that keyfile is used to decrypt drives B, C, D...? | 01:29:01 |
| ElvishJerricco | and B, C, D constitute the LVM that has the root fs? | 01:29:12 |
| sss | like i have drive a,b,c lvm for root with different keys on d,e,f | 01:29:52 |
| ElvishJerricco | ok sure; but the basic idea of "root is on encrypted drives, the key is on these different unencrypted drives" is right, yea? | 01:30:37 |
| sss | yes | 01:30:49 |
| ElvishJerricco | cool, just making sure I understand your use case right | 01:30:59 |
| sss | and it is complicated yes, but to to a long history of data storage | 01:31:31 |
