| 22 Apr 2023 |
 @hexa:lossy.network | with impermanence even | 12:38:03 |
 oddlama | oh, then I must have missed some option in my config that defines boot.initrd.postDeviceCommands | 12:38:46 |
 @lily:lily.flowers | The ZFS nixos module enables it. Hold on let me link github | 12:38:59 |
| @lily:lily.flowers | It needs to be updated after those assertions were added | 12:39:05 |
| @lily:lily.flowers | https://github.com/NixOS/nixpkgs/pull/226237#issuecomment-1518633144 | 12:39:30 |
 @aktaboot:tchncs.de | is it at this stage that the luks disks get decrypted ? | 12:39:44 |
| @aktaboot:tchncs.de | I guess so | 12:40:02 |
| oddlama | In reply to @lily:lily.flowers
https://github.com/NixOS/nixpkgs/pull/226237#issuecomment-1518633144 Thanks that's exactly what I'm running into. | 12:40:05 |
| oddlama | Guess I'll have to look at that later today | 12:40:49 |
| @lily:lily.flowers | In reply to @aktaboot:tchncs.de
is it at this stage that the luks disks get decrypted ? If the disk is neededForBoot (which is any disk to get /, /nix, /nix/store by default iirc) | 12:41:35 |
| @aktaboot:tchncs.de | oh, I set it up directly with initrd.luks.devices | 12:42:55 |
| @aktaboot:tchncs.de | * oh, I set it up directly with bott.initrd.luks.devices | 12:43:02 |
| @lily:lily.flowers | In reply to @aktaboot:tchncs.de
oh, I set it up directly with bott.initrd.luks.devices Oh oops yeah, that's right. The luks stuff happens at a higher level than filesystems (I should maybe go make coffee this morning...) | 12:43:58 |
| @aktaboot:tchncs.de | so systemd in the initrd is still experimental, or fairly stable at this point ? Also what major benefits/features does it bring ? | 12:45:28 |
| @lily:lily.flowers | In reply to @aktaboot:tchncs.de
so systemd in the initrd is still experimental, or fairly stable at this point ? Also what major benefits/features does it bring ? Experimental but mostly working now, enough to let more people tinker with it. The only thing it's really missing tbh now that the filesystem dependency ordering stuff is fixed is fixing the ISO generation to work with it | 12:46:27 |
| @lily:lily.flowers | (I did plan to get to that eventually...) | 12:47:27 |
| @lily:lily.flowers | (I know vaguely what needs to be done, but it's mostly a matter of conditionalizing and redoing the logic for ISO image bootloader stuff iirc) | 12:48:19 |
 @elvishjerricco:matrix.org | In reply to @lily:lily.flowers
If the disk is neededForBoot (which is any disk to get /, /nix, /nix/store by default iirc) Actually boot.initrd.luks only operates in stage 1. It shouldn't be that way. It should drop the initrd from the name and use /etc/crypttab for stage 2 when possible. | 13:26:42 |
| @elvishjerricco:matrix.org | In reply to @oddlama:matrix.org
oh, then I must have missed some option in my config that defines boot.initrd.postDeviceCommands We deliberately do not support the boot.initrd.*Commands options (and my PR that unhides the docs also adds assertions informing you of this). This is because they're fundamentally antithetical to the whole concept of declarative, parallel booting of initrd | 13:28:07 |
| @elvishjerricco:matrix.org | Modules that used those things are re-implemented for systemd stage 1 | 13:28:29 |
| @elvishjerricco:matrix.org | Actually, many of them are just pulled in from upstream units | 13:28:43 |
| @elvishjerricco:matrix.org | because that's possible now | 13:28:48 |
| @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
Actually boot.initrd.luks only operates in stage 1. It shouldn't be that way. It should drop the initrd from the name and use /etc/crypttab for stage 2 when possible. (Yeah I had realized that in my following message because the luks part of their question didn't register in my brain. It would be nice to allow some of that to happen stage 2 though) | 13:29:59 |
| @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
Modules that used those things are re-implemented for systemd stage 1 Yeah but apparently some set them unconditionally alongside boot.initrd.systemd.* and expected them to be ignored, which is no longer the case with the assertions
We probably should have done a more thorough pass to make sure no modules (like the zfs) module would have asserted by default like that when mixing with systemd stage 1 | 13:31:16 |
| @elvishjerricco:matrix.org | I actually was unable to find one that hasn't done the necessary mkIf in nixpkgs | 13:32:48 |
| @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
I actually was unable to find one that hasn't done the necessary mkIf in nixpkgs It might only be the zfs one that was missed then. I haven't done a pass myself to look for others | 13:33:49 |
| @elvishjerricco:matrix.org | Hm I thought I tested that one... | 13:34:30 |
