| 9 Nov 2022 |
 @elvishjerricco:matrix.org | It literally just has a dumb check on your fileSystems with ZFS FSes, and checks if any of them are neededForBoot | 07:37:23 |
| @elvishjerricco:matrix.org | Then the appropriate pools are done in stage 1 instead of stage 2 | 07:37:34 |
 @uep:matrix.org | realistically you'd only care to specify those for boot timing-sensitive ones, but still | 07:37:44 |
| @uep:matrix.org | oh, sure. | 07:37:46 |
| @uep:matrix.org | I think that would work great, and it's really only an optimisation anyway | 07:38:33 |
| @elvishjerricco:matrix.org | but a zfs.pools.<name> option sounds like a good idea generally anyway. Like we could specify extra pools that need to be done in stage 1 for whatever reason; we could specify device units to depend on; we could specify whether it should be automounted; etc. | 07:38:49 |
| @uep:matrix.org | tiny rpool device and nix store on something else, perhaps.. | 07:42:39 |
| @uep:matrix.org | rare, somewhat contrived, but moderately plausible scenarios | 07:43:01 |
| @elvishjerricco:matrix.org | well nixos would still detect that | 07:43:11 |
| @elvishjerricco:matrix.org | it detects all pools with fileSystems that are neededForBoot, which of course includes the one containing /nix/store | 07:43:37 |
| @uep:matrix.org | because of the neededForBoot, right. | 07:43:44 |
| @uep:matrix.org | I guess /var/log is also there, which was my other scenario, but I'm sure there are more | 07:44:28 |
| @uep:matrix.org | oh, an even better one. again with the multi-host scenario: don't actually boot unless you can import the whatever-active-data pool | 07:46:14 |
| @uep:matrix.org | In reply to @elvishjerricco:matrix.org
but a zfs.pools.<name> option sounds like a good idea generally anyway. Like we could specify extra pools that need to be done in stage 1 for whatever reason; we could specify device units to depend on; we could specify whether it should be automounted; etc. different scrub options / schedules per pool | 07:49:51 |
| @elvishjerricco:matrix.org | yep, very good idea | 07:50:13 |
| 10 Nov 2022 |
 Paul Haerle | iiuc, only openvpn-in-initrd is blocking https://github.com/NixOS/nixpkgs/pull/169116 ? Is that deemed important for backwards compability? | 09:46:35 |
| Paul Haerle | Not sure hwo many people are connecting to openvpn networks from their initrd; i personally don't. But if that's all that is needed for a merge, I'd be willing to invest a day or so into that project :) | 09:49:03 |
 @me:linj.tech | How can I get the log when stage 1 fails? | 17:45:30 |
| @me:linj.tech | 
Download image.png | 17:46:00 |
 Arian | You need to set an emergency shell | 17:46:20 |
| Arian | (maybe we should ship one?) | 17:46:41 |
| @elvishjerricco:matrix.org | we do | 17:46:48 |
 K900 | I think it's just the "root account is locked" that's the issue | 17:46:58 |
| K900 | There's a way to override it somewhere | 17:47:02 |
| @elvishjerricco:matrix.org | boot.initrd.systemd.emergencyAccess = true|hashed password | 17:47:03 |
| K900 | That I never remember | 17:47:05 |
| @elvishjerricco:matrix.org | true means it's accessible without a password. | 17:47:29 |
| @elvishjerricco:matrix.org | I always set mine to boot.initrd.systemd.emergencyAccess = config.users.users.root.hashedPassword; | 17:48:00 |
| @elvishjerricco:matrix.org | which I think would be a decent idea to use as default if the root user hashed password is set... | 17:48:24 |
| @me:linj.tech | 
Download image.png | 18:11:07 |
