| 23 May 2023 |
 @elvishjerricco:matrix.org |
No, Stratis is unrelated to LVM and a simpler design
mberndt Huh. For some reason I thought stratis was a management tool for a variety of underlying tech like lvm
| 16:16:08 |
 @gdamjan:spodeli.org | stratis is an opinionated subset of LVM + XFS (I think) | 18:11:14 |
| @gdamjan:spodeli.org | doesn't even do raid :/ | 18:11:24 |
 @mberndt:matrix.org | In reply to @gdamjan:spodeli.org
stratis is an opinionated subset of LVM + XFS (I think) It's not based on LVM. | 18:56:12 |
| @mberndt:matrix.org | It uses DM though. | 18:56:23 |
 Arian | hmm. I think doing NixOS activation in the initrd was a mistake. You can't boot images with systemd-nspawn anymore that use systemd initrd | 21:43:35 |
| Arian | We should move it to early stage-2 | 21:44:09 |
| Arian | Using a DefaultDependencies=no systemd unit | 21:44:31 |
| @elvishjerricco:matrix.org | Couple things | 21:44:41 |
| @elvishjerricco:matrix.org |
- we literally can't move it early enough in stage 2 unless it's pre-systemd, because it sets up etc and therefore the systemd units
| 21:45:08 |
| Arian | for systemd units we can use the SYSTEMD_UNITS env var | 21:45:34 |
| @elvishjerricco:matrix.org |
- It gets us a lot to have it in stage 1. Like if anything in activation fails we get a proper recovery environment
| 21:45:40 |
| Arian | (This is documented and stable) | 21:45:44 |
| @elvishjerricco:matrix.org | There's also a lot of stuff that's down in activation that expects to come before stage 2 systemd | 21:46:46 |
| @elvishjerricco:matrix.org | And where is SYSTEMD_UNITS documented? (On my phone at the moment; hard to check) | 21:47:08 |
| Arian | You can get a recovery system from stage 2. just systemctl isolate rescue.target | 21:49:11 |
| Arian | hmm wait that wont always work if activation fails | 21:49:11 |
| Arian | Perhaps we can make it configurable and/or idempotent | 21:49:11 |
| Arian | run activation both in stage-1 and stage-2. if it already ran in stage-1 it's a no-op | 21:49:11 |
| Arian | Like. nixos-container probably doesn't work anymore once you enabled systemd initrd. which is bad | 21:49:12 |
| Arian | We shouldn't break that | 21:49:12 |
| @elvishjerricco:matrix.org | Containers already get lots of special treatment | 21:49:46 |
| @elvishjerricco:matrix.org | We can just continue that tradition and have a regular init thingy for them | 21:50:04 |
| Arian | hmmph maybe. need to give it some thought during sleep | 21:50:43 |
| @elvishjerricco:matrix.org | I mean, the more we can kill from activation, the better. Personally I'd like to see it eliminated entirely. But as is, I think the expectation is that it comes before stage 2 | 21:53:09 |
| Arian | activation script in the old initrd also doesnt work in nspawn :) (tries to run echo ${pkgs.kmod}/bin/modprobe > /proc/sys/kernel/modprobe and fails) | 22:14:29 |
| @elvishjerricco:matrix.org | yea I was wondering if that ever worked to begin with :P | 22:15:04 |
| Arian | so it's the same amount of broken :) | 22:15:18 |
| @elvishjerricco:matrix.org | In reply to @arianvp:matrix.org
for systemd units we can use the SYSTEMD_UNITS env var (btw I can't find anything about this environment variable; git grep SYSTEMD_UNITS in the systemd repo comes up blank) | 22:18:18 |
| Arian | sorry SYSTEMD_UNIT_PATH | 22:19:11 |
