| 4 Feb 2023 |
 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 |
| @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
Oh btw this is ready for review now that 252.5 is in staging: https://github.com/NixOS/nixpkgs/pull/208269 I left a review with the only comment I had. I'll try running the PR on my own laptop after staging-next is merged, to ensure it doesn't regress anything on my system | 17:08:08 |
| 12 Feb 2023 |
 @kranzes:matrix.org | How's networking support going? | 00:08:59 |
| @elvishjerricco:matrix.org | I've been using it reliably. Seems better than scripted initrd's networking so far. | 00:09:31 |
| @elvishjerricco:matrix.org | That's on my list of things to work on this weekend | 00:09:38 |
| @elvishjerricco:matrix.org | Would like to get it merged soon | 00:09:45 |
| 13 Feb 2023 |
| @elvishjerricco:matrix.org | Lily Foster: FYI apparently I didn't notice that they replaced my PR with one that has the problems I mentioned: https://github.com/systemd/systemd/pull/26367 | 07:11:07 |
| @elvishjerricco:matrix.org | So I'm kinda frustrated, even though that will realistically solve the issue as far as they're concerned (since they seem to think literally only / and /usr will ever be mounted in initrd) | 07:11:46 |
| @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
Lily Foster: FYI apparently I didn't notice that they replaced my PR with one that has the problems I mentioned: https://github.com/systemd/systemd/pull/26367 Yeah I saw :( | 11:58:30 |
| @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
So I'm kinda frustrated, even though that will realistically solve the issue as far as they're concerned (since they seem to think literally only / and /usr will ever be mounted in initrd) I don't even understand why something that just hides the problem rather than fixes it is preferred, since it was never articulated in the thread what is undesirable about a sync point or why the hack is better. Yu just sorta opened a new PR without waiting for your feedback | 12:00:10 |
| 14 Feb 2023 |
| K900 | Bump: https://github.com/NixOS/nixpkgs/pull/210505 | 18:01:36 |
