| 29 Jan 2023 |
 @elvishjerricco:matrix.org | Lily Foster: well the issue with a patch is that it has to go through staging. It's not exactly hard to remove, and there are no mounts that come before sysroot other than those manually configured by people who know what they're doing | 02:45:33 |
| @elvishjerricco:matrix.org | * Lily Foster: well the issue with a patch is that it has to go through staging. The Before ordering is not exactly hard to remove, and there are no mounts that come before sysroot other than those manually configured by people who know what they're doing | 02:46:07 |
 @lily:lily.flowers | Ah, true I didn't think about staging. I'd say that override is fine enough then if it solves that one person's problem | 02:46:39 |
| @lily:lily.flowers | It's better than the current status of things I suppose | 02:46:55 |
| @lily:lily.flowers | I already do similar overrides in my personal config to fix some ordering issues anyway, so it wouldn't cause any problem to add that afaik https://github.com/lilyinstarlight/foosteros/blob/da1db4765c6326537ba8f6aefc30870ff3bda15c/config/base.nix#L112-L126 | 02:48:42 |
| @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
Lily Foster: well the issue with a patch is that it has to go through staging. The Before ordering is not exactly hard to remove, and there are no mounts that come before sysroot other than those manually configured by people who know what they're doing (I was meaning easy to remove as in the patch would fail to apply once a fix is in systemd or that code otherwise changed, and prompt whoever was doing the systemd package update to remove it. A Before override can more easily be forgotten to move) | 02:49:51 |
| @lily:lily.flowers | * (I was meaning easy to remove as in the patch would fail to apply once a fix is in systemd or that code otherwise changed, and prompt whoever was doing the systemd package update to remove it. A `Before` override can more easily be forgotten to remove) | 02:50:08 |
| @lily:lily.flowers | (But it's also not that big a deal either way, I think the override is probably fine as a short-term fix, especially because rebuilds) | 02:51:22 |
| 2 Feb 2023 |
| @elvishjerricco:matrix.org | Can I get a thumbs up from someone on this PR? https://github.com/NixOS/nixpkgs/pull/214048 | 15:26:18 |
| 4 Feb 2023 |
|  jaen joined the room. | 20:22:46 |
| jaen | Should I expect systemd stage1 to reasonably boot?
I have ZFS-in-LVM-in-LUKS setup (LVM is there for separate swap, I've read that swap on ZFS is rather spotty with hibernation and under memory pressure) with separate header and an encrypted keyfile (having the boot pendrive is one factor, knowing the password is the other). This all works with the current stage1, though it needed a bit of `preLVM` and `pre`/`postDeviceCommands` trickery to decrypt the keyfile, use it to open the LUKS container and close it afterwards.
This doesn't work OOtB with systemd-based stage1 - what it basically does is that it seems to go `Finished NixOS Activation.` and then immediately starts stopping all the targets for some reason I can't discern, where it ultimately hands on stopping the keyfile unit- which is not all that surprising, given aforementioned options are not supported, but I tried using things like `keyscript` (it seems to be ignored, is it not supported on NixOS?) and whatever I could find on the intarwebs to set it up by manually writing th crypttab, but it didn't seem to help.
Any pointers? | 20:24:10 |
| jaen | * Should I expect systemd stage1 to reasonably boot with more complex configs?
I have ZFS-in-LVM-in-LUKS setup (LVM is there for separate swap, I've read that swap on ZFS is rather spotty with hibernation and under memory pressure) with separate header and an encrypted keyfile (having the boot pendrive is one factor, knowing the password is the other). This all works with the current stage1, though it needed a bit of `preLVM` and `pre`/`postDeviceCommands` trickery to decrypt the keyfile, use it to open the LUKS container and close it afterwards.
This doesn't work OOtB with systemd-based stage1 - what it basically does is that it seems to go `Finished NixOS Activation.` and then immediately starts stopping all the targets for some reason I can't discern, where it ultimately hands on stopping the keyfile unit- which is not all that surprising, given aforementioned options are not supported, but I tried using things like `keyscript` (it seems to be ignored, is it not supported on NixOS?) and whatever I could find on the intarwebs to set it up by manually writing th crypttab, but it didn't seem to help.
Any pointers? | 20:24:38 |
| jaen | * Should I expect systemd stage1 to reasonably boot with more complex configs?
I have ZFS-in-LVM-in-LUKS setup (LVM is there for separate swap, I've read that swap on ZFS is rather spotty with hibernation and under memory pressure) with separate header and an encrypted keyfile (having the boot pendrive is one factor, knowing the password is the other). This all works with the current stage1, though it needed a bit of `preLVM` and `pre`/`postDeviceCommands` trickery to decrypt the keyfile, use it to open the LUKS container and close it afterwards.
This doesn't work OOtB with systemd-based stage1 - what it basically does is that it seems to go `Finished NixOS Activation.` and then immediately starts stopping all the targets for some reason I can't discern, where it ultimately hangs on stopping the keyfile unit- which is not all that surprising, given aforementioned options are not supported, but I tried using things like `keyscript` (it seems to be ignored, is it not supported on NixOS?) and whatever I could find on the intarwebs to set it up by manually writing th crypttab, but it didn't seem to help.
Any pointers? | 20:29:17 |
| jaen | I was considering adding yubikeys to my keyfiles anyway, so I figured I'll do it and see if it side-steps the issue, but it turns out that's not implemented - https://github.com/systemd/systemd/issues/25228 -_- | 21:13:36 |
| jaen | So I suppose my set-up is just too exotic for systemd. | 21:13:38 |
| jaen | Maybe I'll see if I can get that cryptsetup version with `keyfilescript` and if it doesn't, I guess I'm just out of luck? | 21:14:28 |
| 5 Feb 2023 |
 K900 | Anyone else want to look at https://github.com/NixOS/nixpkgs/pull/210505 ? | 08:21:27 |
| K900 | I've been running it for ages now | 08:21:33 |
| K900 | Should probably just get it in | 08:21:38 |
| 8 Feb 2023 |
| @elvishjerricco:matrix.org | https://github.com/systemd/systemd/pull/26348 | 03:12:31 |
| @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
https://github.com/systemd/systemd/pull/26348 I saw yuwata responded to your PR. Having a pre-any-filesystem sync point would make sense exactly for stuff like hibernate/resume, so I'm not sure what their motivation for limiting the change to just adding Before=sysroot.mount sysusr-usr.mount to systemd-hibernate-resume@.service is (and also shouldn't it be sysusr-usr.mount instead of sysroot-usr.mount, since sysusr-usr.mount comes first?) | 15:20:12 |
| @lily:lily.flowers | Are they concerned about the local part of local-fs-pre? Because there could also just be a new pre-mount target they're after. Because resume docs for kernel are pretty clear it needs to come before all mounts, period | 15:21:09 |
| @lily:lily.flowers | * Are they concerned about the local part of local-fs-pre.target? Because there could also just be a new pre-mount target they're after. Because resume docs for kernel are pretty clear it needs to come before all mounts, period | 15:21:20 |
| @elvishjerricco:matrix.org | I'm worried they're going to tell me to create initrd-fs-pre.target | 22:13:31 |
| @elvishjerricco:matrix.org | I noted that Before=sysroot.mount doesn't even work because then systemd-fsck-root.service can be started simultaneously with systemd-hibernate-resume@.service, which seems broken. | 22:14:52 |
| @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
I'm worried they're going to tell me to create initrd-fs-pre.target I mean that probably wouldn't be a bad thing to have | 22:20:13 |
| @elvishjerricco:matrix.org | It just seems pointless though | 22:24:54 |
| @elvishjerricco:matrix.org | The reason for the difference between local-fs.target and initrd-fs.target is so that initrd-switch-root can pull in initrd-fs and not local-fs, causing the initrd's local-fs units to be unmounted / stopped. But local-fs-pre.target is supposed to not have any Wants dependencies, isn't it? So stopping that for switch-root should be no problem? | 22:29:27 |
| @elvishjerricco:matrix.org | * The reason for the difference between local-fs.target and initrd-fs.target is so that initrd-switch-root can pull in initrd-fs and not local-fs, causing the initrd's local-fs units to be unmounted / stopped. But local-fs-pre.target is supposed to not have any Wants dependencies, isn't it? So stopping that for switch-root when some relevant units are ordered before it should be no problem? | 22:29:41 |
| 9 Feb 2023 |
| @elvishjerricco:matrix.org | Oh btw this is ready for review now that 252.5 is in staging: https://github.com/NixOS/nixpkgs/pull/208269 | 03:23:37 |
