| 6 Oct 2024 |
 ElvishJerricco | K900: There's no stage-2-init.sh in WSL? | 18:44:47 |
 K900 | 
Download {F00EFDA1-168F-4D67-A2CE-8B71D476300B}.png | 18:44:52 |
| K900 | And nope there isn't | 18:44:59 |
| K900 | We do something very silly | 18:45:05 |
| ElvishJerricco | yea systemd is PID 1 on any NixOS system; I guess the better way to say what I meant was stage-2-init-less | 18:45:22 |
| ElvishJerricco | In reply to @k900:0upti.me
We do something very silly what is the very silly? | 18:45:31 |
| ElvishJerricco | it might actually be helpful | 18:45:34 |
| ElvishJerricco | because I want to eliminate stage-2-init in containers | 18:45:45 |
| K900 | We give WSL /sbin/init | 18:45:46 |
| K900 | Which is a small shim binary | 18:45:56 |
| K900 | That runs activation and then execs into real systemd | 18:46:04 |
| ElvishJerricco | oh, so extremely similar to stage-2-init then | 18:46:16 |
| K900 | Yes | 18:46:23 |
| K900 | But stupider | 18:46:26 |
| ElvishJerricco | in fact, why isn't it just stage-2-init? | 18:46:30 |
| K900 | Because WSL explodes if it's a shell script | 18:47:45 |
| ElvishJerricco | oof | 18:48:07 |
| ElvishJerricco | ... so why not just a binary that execs stage-2-init? :P | 18:48:20 |
| K900 | And also because WSL really wants to set up its own /dev /proc etc | 18:48:30 |
| ElvishJerricco | ah | 18:48:36 |
| K900 | I don't really remember all of the stupid things it does | 18:48:40 |
| ElvishJerricco | which is fair | 18:48:40 |
| ElvishJerricco | we shouldn't be doing the special FSes either | 18:48:48 |
| ElvishJerricco | Arian: but yea, I think containers should come with a pre-activated root tree, and starting the container means mounting that tree and the nix store and all that jazz so that systemd can be exec'd as the first PID 1 | 18:50:55 |
| K900 | But yeah if you want to kill stage-2-init, it would be nice to consider the WSL use case | 18:51:14 |
| ElvishJerricco | If we could make that work for WSL too, that'd be great | 18:51:19 |
| K900 | So we can get rid of our very silly binary | 18:51:21 |
 Arian | I have a slightly different philosophy in my head still
Systemd is carefully designed to be able to start up without anything but /usr. All early components can get paths to their config in the nix store. Even systemd itself through SYSTEMD_UNITS env var. There is no need for a pre-activated dir. Systemd should be able to boot just fine with just /nix/store (just like it's able to boot with just /usr).
| 19:25:58 |
| Arian | Another problem our repart build doesn't solve yet which is separate from activation is setting up the initial profile. Which is important as all our boot loader builders require there to be a profile | 19:40:16 |
| ElvishJerricco | In reply to @arianvp:matrix.org
I have a slightly different philosophy in my head still
Systemd is carefully designed to be able to start up without anything but /usr. All early components can get paths to their config in the nix store. Even systemd itself through SYSTEMD_UNITS env var. There is no need for a pre-activated dir. Systemd should be able to boot just fine with just /nix/store (just like it's able to boot with just /usr).
I mean setting the SYSTEMD_UNITS env var is still going to be some pre-PID1 setup | 20:15:58 |
