| 28 Jul 2025 |
 emily | it should almost certainly be a systemd daemon, I think | 17:31:58 |
| emily | (it can be a oneshot or similar though) | 17:32:10 |
| emily | we don't want to add new activation scripts unless it's completely unavoidable | 17:32:13 |
| emily | (and moving stuff out of activation scripts is being worked on) | 17:32:36 |
| emily | (this doesn't necessarily determine where in the options hierarchy to put it though) | 17:34:06 |
 ElvishJerricco | It'll have to support systemd initrd if it's going to be upstreamed. The plan is to phase out scripted initrd over the next year or so, which means scripted-initrd-only things are not acceptable, though systemd-initrd-only things are acceptable. | 17:41:18 |
 magic_rb | Should be fine for ifstate, i run it not in the initrd but on systemd initrd | 17:44:03 |
| emily | ah I see it's already systemd.services.ifstate | 17:44:10 |
| emily | so never mind me about activation scripts | 17:44:16 |
| emily | I would personally probably go for services.ifstate.* IMO, it's comparable to services.network-manager.* in that you have a systemd service managing the config, but I'm ambivalent | 17:44:54 |
| emily | networkd is under systemd.network.* which is its own kind of weird :P | 17:45:01 |
| emily | well,
message = "ifstate.nix does not currently implement a systemd unit for initrd. Please continue to use the scripted stage one for the time being.";
| 17:45:11 |
| emily | so yeah we'd want to drop the initrd support for upstreaming or else implement systemd initrd support (and probably only systemd initrd support) | 17:45:27 |
| magic_rb | In reply to @emilazy:matrix.org
well,
message = "ifstate.nix does not currently implement a systemd unit for initrd. Please continue to use the scripted stage one for the time being.";
I dont see why it couldnt, at least v1, i havent used v2 | 17:45:37 |
| emily | (we are hoping to flip the default to systemd initrd within the month) | 17:45:38 |
| emily | I didn't say couldn't :P I'm just talking about what the module actually says, in the context of upstreaming it | 17:45:52 |
| magic_rb | In reply to @emilazy:matrix.org
(we are hoping to flip the default to systemd initrd within the month) (Finally) | 17:45:55 |
| magic_rb | In reply to @emilazy:matrix.org
I didn't say couldn't :P I'm just talking about what the module actually says, in the context of upstreaming it Ah okay | 17:46:01 |
 Marcel | In reply to @emilazy:matrix.org
so yeah we'd want to drop the initrd support for upstreaming or else implement systemd initrd support (and probably only systemd initrd support) i've just never came to create a unit, because all my sytems still use scrypted stage 1 - allthough thats something, that i will definitely add | 17:47:14 |
| emily | the initrd stuff should also probably be under boot.initrd.* so you can have distinct config in initrd, that's how it works for repart and networkd though not 100% sure | 17:47:25 |
| emily | (I think maybe networkd might inherit config from stage 2 or something weird like that, I forget) | 17:47:52 |
| emily | I think we can also just upstream without initrd support initially FWIW, and add it later | 17:48:31 |
| ElvishJerricco | (this is something I've debated with myself a lot; we currently don't inherit configs from stage 2 for basically anything and I can't decide if that's a good thing or not. The networkd exception is that if you use boot.initrd.network.enable rather than boot.initrd.systemd.network.enable you get the networking.interfaces implementations from stage 2 basically) | 17:48:45 |
| emily | (but I don't think we'll want to upstream scripted initrd support, since it's going to explicitly be on the deprecation/warning path very very soon) | 17:48:47 |
| emily | thankfully fixed by deprecating networking.interfaces | 17:49:03 |
| Marcel | That's at least what I am currently doing. If you don't specify a initrd config and ifstatenis activated on initrd, it inherits the normal config | 17:49:10 |
| emily | I think it's easy to inherit if you want and annoying to disable automatic inheritance if you don't | 17:49:17 |
| emily | so IMO separate configs and letting people manually do explicit inheritance is the way to go | 17:49:27 |
| emily | initrd isn't the same as the booted machine | 17:49:37 |
| emily | (they even have different notions of machine-id by default) | 17:49:42 |
