| 9 Oct 2024 |
 aloisw | In reply to @emilazy:matrix.org
it also doesn't solve colocating with Windows or whatever (with obvious sacrifice to reliability) Does windows not support UDF? (Not familiar enough with its boot process to know whether that would be enough though.) | 20:02:42 |
 emily | for booting? idk | 20:02:52 |
|  schuelermine changed their profile picture. | 23:46:47 |
| 10 Oct 2024 |
 ElvishJerricco | huh, apparently systemd-cryptsetup doesn't know how to use systemd credentials for anything except the root volume | 01:36:22 |
| ElvishJerricco | * huh, apparently systemd-cryptsetup doesn't know how to use systemd credentials for anything except the volume named root | 01:36:30 |
| ElvishJerricco | that's actually very frustrating. | 01:36:43 |
| ElvishJerricco | well, I guess I should check the code. It might just be undocumented | 01:37:09 |
| ElvishJerricco | hm, no it looks like the credentials apply to all volumes. But it's the same credentials. i.e. Every volume sees the same keys | 01:39:45 |
| ElvishJerricco | Which is just as frustrating. I was hoping to rip out all the clevis stuff tonight and replace it all with systemd credentials. | 01:40:20 |
| ElvishJerricco | wait no I think my mental model is just a little wrong | 01:41:46 |
| ElvishJerricco | ok I think both gpt-auto-generator and cryptsetup-generator generate systemd-cryptsetup@.service instances that have ImportCredential=cryptsetup.*, meaning all these instances would use the same creds by default, but you could override what each of them is getting with e.g. LoadCredential=cryptsetup.passphrase:/foo | 01:46:19 |
| ElvishJerricco | which means I can rip out clevis, I think | 01:46:40 |
| ElvishJerricco | (rip it out into it a separate credential-provider service / socket, that is) | 01:47:13 |
| ElvishJerricco | Still frustrating because I was hoping to use the credential ID provided over the socket to determine which jwe to use, but these are all using the same credential ID so I'll have to figure something else out | 01:48:35 |
 Arian | ya'll okay with merging https://github.com/NixOS/nixpkgs/pull/347303 ? | 09:52:42 |
|  p4cmanus3r joined the room. | 13:26:03 |
| 11 Oct 2024 |
 mjm | hit a weird ordering cycle with preservation (mounts and tmpfiles in initrd) and the etc overlay https://github.com/WilliButz/preservation/issues/5
emily told me this room may be interested
| 03:25:14 |
| ElvishJerricco | mjm: huh, why does /sysroot/nix depend on tmpfiles? | 04:13:11 |
| mjm | preservation does that with all its mounts, to i guess set up the mountpoints with expected permissions? | 04:13:45 |
| ElvishJerricco | that's backwards | 04:14:28 |
| ElvishJerricco | you would need to have the mount occur before tmpfiles to use tmpfiles to set perms on the mounted fs | 04:14:47 |
| mjm | well, it does both | 04:14:57 |
| mjm | it does it for both ends of the bind mount | 04:15:03 |
| ElvishJerricco | same thing though? | 04:15:29 |
| mjm | isn't setting the permissions on the source of the bind mount the same as setting them on the target after it's mounted? | 04:16:04 |
| ElvishJerricco | also it's... a bind mount. You only need to do one of them. But yea either way tmpfiles can happen last | 04:16:08 |
| mjm | yeah i don't really know their reasoning for wanting to do it before | 04:17:02 |
| ElvishJerricco | https://github.com/WilliButz/preservation/blob/02e731a820d05107bc648460f8630d0d80a5ffd4/lib.nix#L289-L290
yea, uh, no, absolutely not. This isn't even initrd. Your file systems are in local-fs, which is before tmpfiles
| 04:17:29 |
| ElvishJerricco | that's inherently a cylce | 04:17:36 |
| mjm | that's not the branch used for initrd tho | 04:18:02 |
