| 28 Jul 2025 |
 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 |
| Marcel | In reply to @emilazy:matrix.org
I think it's easy to inherit if you want and annoying to disable automatic inheritance if you don't Just the default, the pint you start configuring initrd stuff it is replaced and not merged | 17:50:40 |
| Marcel | If you want to merge it, you have to do it yourself as the consumer | 17:51:01 |
| emily | I think that's not ideal (because if you import a module that only intends to extend the initrd network config, it unexpectedly blows away the inherited config) | 17:51:15 |
| Marcel | Ok, I'll leave the default initrd config:) | 17:51:50 |
| emily | I think it should match boot.initrd.system.network by being separate (and in a separate hierarchy) and you can always boot.initrd.networking.ifstate = config.networking.ifstate; or such | 17:51:53 |
| emily | (admittedly the boot.initrd.* hierarchy is a bit of a mess currently) | 17:52:06 |
| Marcel | In reply to @emilazy:matrix.org
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 you are still with services.ifstate? in your last message you used networking.ifstate? | 19:16:08 |
| emily | I have no consistent opinion 😅 NM is under networking.* right? | 19:16:59 |
| emily | I'd match NM | 19:17:01 |
| Marcel | yeah | 19:17:21 |
