| 11 Oct 2022 |
 flokli | I just pressed the button :-) let's get this in, if it ends up accidentally breaking something, we can always revert. | 22:56:55 |
| 12 Oct 2022 |
 colemickens | ElvishJerricco: have you looked at openvpn task for the network-initrd PR? I keep wishing it were merged... | 17:23:52 |
 @elvishjerricco:matrix.org | colemickens: To me the bigger blocker is the question about whether/how to auto-configure interfaces, like how the scripted initrd networking does | 17:35:09 |
| @elvishjerricco:matrix.org | That question needs to be answered. I wouldn't mind openvpn coming in a later PR | 17:35:22 |
| @elvishjerricco:matrix.org | It's not clear to me that we should auto-configure interfaces, and if we should, it's not clear to me how, particularly because of people who just use networking.useDHCP rather than configuring individual interfaces | 17:36:41 |
| @elvishjerricco:matrix.org | (though I guess that's deprecated isn't it? So we could just not support it with systemd stage 1 networking...) | 17:37:05 |
| @elvishjerricco:matrix.org | Oh there's also boot.initrd.network.flushBeforeStage2, which is true by default with scripted initrd, but systemd-networkd behaves as though it's false right now | 17:38:18 |
| @elvishjerricco:matrix.org |
When systemd-networkd exits, it generally leaves existing network devices and configuration intact. This makes it possible to transition from the initramfs and to restart the service without breaking connectivity. This also means that when configuration is updated and systemd-networkd is restarted, netdev interfaces for which configuration was removed will not be dropped, and may need to be cleaned up manually.
| 17:39:21 |
| colemickens | Does it make sense to say init-networkd is only supported if you also use networkd in stage-2? | 17:40:57 |
| colemickens | and at that point, can you just wholly use the stage-2's networkd config for stage-1, maybe letting the user override it if they wanted to? | 17:41:26 |
| @elvishjerricco:matrix.org | Ehh.... Two problems. 1) We would only want to copy a subset of stage 2 config. For instance we probably can't expect to be able to bring up wireguard netdevs due to a lack of secrets. 2) I'm sure there are people who want to use e.g. NetworkManager in stage 2 but still want to e.g. unlock LUKS remotely in stage 1. | 17:43:02 |
| @elvishjerricco:matrix.org | Aren't NetworkManager and systemd-networkd... a little bit mutually exclusive? | 17:43:21 |
| @elvishjerricco:matrix.org | (I actually do not know) | 17:43:35 |
| colemickens | eh, I think you're right enough either way | 17:44:03 |
| colemickens | on both points | 17:44:11 |
| colemickens | I'll think about it some more, I had forgotten about these things that do seem much more important than special support for openvpn | 17:44:36 |
| @elvishjerricco:matrix.org | I think it'd be great to reuse some subset of stage 2 networkd configuration when possible, but I have no idea what subset we can automatically decide to use | 17:44:39 |
| @elvishjerricco:matrix.org | I mean the obvious answer is "You're the admin; you figure it out" and don't automate it at all, which is kinda the current approach in the PR | 17:45:21 |
| colemickens | "automatically" seems to get hairy the more I think about what that would mean | 17:45:25 |
| colemickens | In reply to @elvishjerricco:matrix.org
I mean the obvious answer is "You're the admin; you figure it out" and don't automate it at all, which is kinda the current approach in the PR are we opposed to that, or that as a starting point? | 17:45:48 |
| colemickens | I didn't find it that unworkable, and I wound up sharing config between stage-1/2 as I found appropriate. It's a bit much, but so is trying to do stage-1 networking imo | 17:46:14 |
| @elvishjerricco:matrix.org | I think there's one bare minimum thing we should probably do: When the user has networking.interfaces.<name>.useDHCP = true, or networking.useDHCP = true, handle it the same way in stage 1 that we do in stage 2, and that's it. | 17:46:50 |
| @elvishjerricco:matrix.org | * I think there's one bare minimum thing we should probably do: When the user has networking.interfaces.<name>.useDHCP = true, or networking.useDHCP = true, handle it the same way in stage 1 that we do in stage 2 for networkd, and that's it. | 17:47:01 |
| @elvishjerricco:matrix.org | Frankly I'm pretty sure that's all we do in scripted stage 1, so that would be feature parity. And it doesn't seem hard | 17:47:19 |
| * colemickens nods | 17:48:31 |
| @elvishjerricco:matrix.org | I could see an argument for wanting to handle boot.initrd.network.flushBeforeStage2 thing, but frankly I'd be perfectly happy with a warning/assertion that says "Yo that's gotta be false now" | 17:49:37 |
 @kranzes:matrix.org | In reply to @flokli:matrix.org
I just pressed the button :-) let's get this in, if it ends up accidentally breaking something, we can always revert. https://nixpk.gs/pr-tracker.html?pr=189676 | 18:53:25 |
| flokli | In reply to @elvishjerricco:matrix.org
I think there's one bare minimum thing we should probably do: When the user has networking.interfaces.<name>.useDHCP = true, or networking.useDHCP = true, handle it the same way in stage 1 that we do in stage 2 for networkd, and that's it. I think the main problem is that we match by name here, not Interface types etc | 18:56:25 |
| flokli | There is semi-sane ways to tell networkd to try to DHCP on real Ethernet links if nothing else is configured | 18:56:57 |
| flokli | You don't need to only match by name. Obviously, doing this on /all/ interfaces no matter what breaks some stuff in odd ways. | 18:57:42 |
