| 28 Jul 2025 |
 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:envs.net | 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 |
