| 22 Apr 2023 |
 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 |
| @elvishjerricco:matrix.org | ok the assertion just isn't working for some reason | 13:41:02 |
| @elvishjerricco:matrix.org | Or... the way I'm testing it isn't working? I'm confused | 13:42:08 |
| @elvishjerricco:matrix.org | Yea wtf assertions?
$ nix eval -f ./nixos --arg configuration '{fileSystems."/" = { device = "fo"; fsType = "zfs"; }; boot.loader.grub.device = "nodev"; networking.hostId = "deadbeef"; }' config.boot.initrd.postDeviceCommands
<very much not the empty string>
$ nix build -f ./nixos --arg configuration '{fileSystems."/" = { device = "fo"; fsType = "zfs"; }; boot.loader.grub.device = "nodev"; networking.hostId = "deadbeef"; }' system
<builds fine>
| 13:44:30 |
| @aktaboot:tchncs.de | but doesn't stage2 happen after mounting the rootfs ? (which in some cases is luks encrypted) so how would that be ? | 13:45:02 |
| @aktaboot:tchncs.de | only reading it from the comments in stage-1.nix | 13:45:24 |
| @elvishjerricco:matrix.org | aktaboot: The file systems that have to be mounted in stage 1 also need to have their LUKS drives decrypted in stage 1 | 13:45:32 |
| @elvishjerricco:matrix.org | But this is not all file systems | 13:45:48 |
| @elvishjerricco:matrix.org | It's not uncommon to have file systems and disks that only need to be done in stage 2 | 13:46:17 |
| @elvishjerricco:matrix.org | but we currently always do luks in stage 1 | 13:46:25 |
| @elvishjerricco:matrix.org | You can do it in stage 2 yourself by configuring /etc/crypttab though | 13:46:36 |
| @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
Hm I thought I tested that one... https://github.com/NixOS/nixpkgs/blob/9ea57a7a020823ff80dd3afbda037036e7392f21/nixos/modules/tasks/filesystems/zfs.nix#L534-L545 | 13:46:44 |
