| 1 Mar 2025 |
 emily | yeah, would be cool. | 14:08:28 |
| emily | I personally don't think that pointy-clicky configuration is a market it makes sense for NixOS to target at all right now but partitioning is indeed uniquely annoying/fiddly | 14:09:31 |
 Arian | Yeh but if not point clicks at least not imperative | 14:12:48 |
 raitobezarius | In reply to @emilazy:matrix.org
I personally don't think that pointy-clicky configuration is a market it makes sense for NixOS to target at all right now but partitioning is indeed uniquely annoying/fiddly I agree but also almost everyone I know starts by using the graphical installer | 14:32:55 |
| raitobezarius | which horrifies me | 14:32:57 |
| emily | yes, I mean it's very appealing | 14:33:44 |
| emily | I just think it gives a bad impression because as a graphical installer it's not very polished, and as a prelude to the "NixOS experience" it's incredibly misleading | 14:33:44 |
| emily | it's like we built a really ornate-looking stairs and door with a nice soft doormat but when you open it it falls off the hinges a little and then when you walk inside you immediately end up in a maintenance crawlspace | 14:34:16 |
| 2 Mar 2025 |
 @elvishjerricco:matrix.org | I just realized... I've long complained that nixos-generate-config unlocks any encrypted file system during stage 1, when that usually only needs to be done for the root FS. But I just realized, we could use the fileSystems.*.encrypted options to determine which drives to unlock in stage 1 based on fsNeededForBoot. Just needs a bit more logic to make a stage 2 crypttab and a pretty simple change to nixos-generate-config | 01:06:14 |
 uep | when that's using LUKS, and the same passphrase is used, it gets cached/reused over multiple devices. Would such a split mean getting prompted twice? | 01:19:16 |
| @elvishjerricco:matrix.org | In reply to @uep:matrix.org
when that's using LUKS, and the same passphrase is used, it gets cached/reused over multiple devices. Would such a split mean getting prompted twice? Not with systemd initrd because systemd initrd caches the password in the kernel key ring | 01:22:17 |
| uep | cool, wasn't sure if that would persist from one to the other, that's all. | 01:25:16 |
| 3 Mar 2025 |
|  bendanm joined the room. | 04:43:22 |
|  mornix joined the room. | 04:51:17 |
| 4 Mar 2025 |
| Arian | So when ProtectSystem is set in system.conf then initrd remounts /usr as read-only. I wonder if we should patch that behaviour in pid1 to do the same for /nix/store ? | 13:55:29 |
| Arian | * So when ProtectSystem is set in system.conf then pid1 remounts /usr as read-only. I wonder if we should patch that behaviour in pid1 to do the same for /nix/store ? | 13:55:42 |
| raitobezarius | isn't /nix/store already RO? | 13:57:01 |
| emily | don't we already do a fancy bind-mount thing for the store? | 13:57:30 |
| emily | or are you proposing we use systemd to do it? | 13:57:36 |
| Arian | /nix/store is not RO in initrd | 13:58:27 |
| Arian | it’s writeable | 13:58:29 |
| emily | yikes | 13:58:42 |
| raitobezarius | no problem: https://gerrit.lix.systems/c/lix/+/2690 | 13:59:05 |
| Arian | it’s just /sysroot/nix/store that we remount as read-only | 13:59:06 |
| emily | and I guess we don't need the fancy bind mount stuff because the daemon isn't running in stage 1 anyway? | 13:59:07 |
| emily | typo: "Flancher" 😆 | 13:59:42 |
| raitobezarius | this is the 2nd time someone told me | 13:59:50 |
| raitobezarius | i am fixing it now | 13:59:51 |
| raitobezarius | Elvish never told me the typo btw | 13:59:54 |
| raitobezarius | done | 14:00:06 |
