| 23 Sep 2022 |
 @elvishjerricco:matrix.org | sure, either way | 02:14:45 |
| @elvishjerricco:matrix.org | just seemed better than patching actual code, y'know? | 02:15:04 |
 Zhaofeng Li | Actually /run/opengl-driver doesn't appear to be very extensible at the moment 🥲 | 02:17:29 |
| @elvishjerricco:matrix.org | yea i've had ideas for things to do similar to that but there isn't really a good mechanism in place. That'd be a nice improvement to make to nixos | 02:18:38 |
 @oxalica:matrix.org | In reply to @zhaofeng:zhaofeng.li
If we add it in a fixed runtime path, something like /run/opengl-driver (I remember an RFC to change the name) seems better than /etc is /run already populated in initrd stage? | 02:40:36 |
| @elvishjerricco:matrix.org | Not exactly so we'd have to also set it up separately in initrd before luks devices start coming online. | 02:47:23 |
| @oxalica:matrix.org | In reply to @elvishjerricco:matrix.org
Not exactly so we'd have to also set it up separately in initrd before luks devices start coming online. mounting another tmpfs just for this seems not convincing | 03:44:41 |
| @elvishjerricco:matrix.org | i mean it's the same tmpfs | 03:45:08 |
| @elvishjerricco:matrix.org | /run is the same from before anything starts in stage 1 all the way to the very end of shutdown | 03:45:33 |
| @elvishjerricco:matrix.org | well, systemd starts as pid 1 in stage 1 and mounts /run, /dev, /proc, and /sys before starting anything | 03:45:58 |
| @elvishjerricco:matrix.org | but yea we would have to do the setup twice, once in stage 1 and once in stage 2 | 03:46:32 |
 @janne.hess:helsinki-systems.de | But who populates /run in stage 1? | 08:15:46 |
| @janne.hess:helsinki-systems.de | We're about to rebuild the activation script from stage 2 here | 08:16:25 |
| @elvishjerricco:matrix.org | Janne Heß: It'd just have to be a service with Before=cryptsetup-pre.target | 08:16:35 |
| @elvishjerricco:matrix.org | In reply to @janne.hess:helsinki-systems.de
We're about to rebuild the activation script from stage 2 here (as a brief aside, arguably stage 1 and stage 2 should actually be almost the same infrastructure, and it should simply be possible to make a NixOS config that's as stripped down as stage 1 needs to be) | 08:17:56 |
| @elvishjerricco:matrix.org | In reply to @janne.hess:helsinki-systems.de
We're about to rebuild the activation script from stage 2 here * (as a brief aside, arguably stage 1 and stage 2 should actually be almost the same infrastructure, and it should simply be possible to make a NixOS config that's as stripped down as stage 1 needs to be; main difference between the two being make-initrd-ng closures instead of nix closures) | 08:18:30 |
 K900 | Now that I think about it, I wonder if we could do a crime on WSL | 08:20:06 |
| K900 | And basically have initrd-as-root | 08:20:14 |
| K900 | And reuse all the systemd-in-stage1 stuff | 08:20:30 |
| K900 | For context, the latest WSL update added native systemd-as-PID1 support | 08:20:56 |
| K900 | But it doesn't have a good way to run the activation scripts | 08:21:09 |
| @janne.hess:helsinki-systems.de | Maybe a question for #wsl:nixos.org ? | 08:21:42 |
| @elvishjerricco:matrix.org | I believe I've mentioned before that my zeroth attempt at systemd in stage 1 was literally just doing a nested nixos eval with lots of hacks stripping things out and then putting that in an initrd :P | 08:21:47 |
 @arianvp:matrix.org | Happy to commit crimes on WSL | 08:21:54 |
| K900 | In reply to @janne.hess:helsinki-systems.de
Maybe a question for #wsl:nixos.org ? I've been posting there about my experiments with wrapping systemd | 08:22:50 |
| K900 | So far kinda feels like the wrapper route is still easier | 08:27:16 |
| K900 | Even though it makes things kinda awkwaed | 08:27:27 |
| K900 | * Even though it makes things kinda awkward | 08:27:31 |
 flokli | Arian: will you bring your windows laptop? | 19:12:37 |
| Zhaofeng Li | In reply to @elvishjerricco:matrix.org
Zhaofeng Li: While I'm largely OK with https://github.com/NixOS/nixpkgs/pull/189676/ I had another thought about the patch. Couldn't we just change that hard coded absolute path to something in /etc and configure said directory in NixOS with environment.etc rather than taking on the risk that we could be wrong about relative paths being safe? Just looked at it, and it seems that adding a new /run/cryptsetup-libraries seems unappealing to people and /run/opengl-drivers doesn't look like a good place either. We can do /run/current-system/cryptsetup-libraries but then ABI breakages may occur (discussion). | 20:49:59 |
