| 17 Apr 2026 |
|  c4lliope changed their profile picture. | 08:41:46 |
|  dish [Fox/It/She] changed their profile picture. | 16:58:37 |
| 18 Apr 2026 |
 sss | Failed assertions:
- boot.initrd.luks.devices.<name>.preOpenCommands and postOpenCommands is not supported by systemd stage 1. Please bind a service to cryptsetup.target or cryptsetup-pre.target instead.
how to do it nowdays ? | 01:09:54 |
 hexa | write a systemd unit in initrd instead | 01:11:17 |
| hexa | boot.inird.systemd.services.<yourunit> = { ... } | 01:12:20 |
| hexa | I would interpret binding as using BindsTo | 01:12:58 |
 ElvishJerricco | Oh uhh "bind to" is probably a bad choice of words for the assertion message then :P | 01:16:17 |
| sss | so i need to create 2 services, one with BindsTo and second which depends on cryptsetup.target ? | 01:16:32 |
| ElvishJerricco | It's only meant to tell you to make a systemd service relative to the cryptsetup target that's relevant to you | 01:17:01 |
| hexa | was gonna say this feels not correct, but got distracted | 01:18:38 |
| sss | so.... ? | 01:19:35 |
| 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 |
