Simon McVittie wrote: > On Sun, 22 Sep 2024 at 12:22:50 +0200, Chris Hofstaedtler wrote: > > d-i could make (or offer) a choice between networkd and > > NetworkManager. > > d-i *already* makes a choice between ifupdown and NetworkManager: if > NM has been pulled in by a task's dependencies (e.g. this happens when > you install the GNOME or KDE desktop, among others), it writes out NM > config, else it writes out ifupdown config. I believe a 1:1 replacement > of ifupdown with networkd in the packages and configuration provided by > new installations would do what I think you're proposing.
There's one other desirable feature that would make this a robust solution: having NetworkManager do something to handle or ignore interfaces managed by networkd. Currently, NetworkManager has a plugin for ifupdown; it doesn't allow NM to *manage* interfaces handled by ifupdown (other than bringing them up or down), but it's enough to ensure that NM doesn't disrupt ifupdown-managed networking. (That's important, for instance, to make sure that installing NetworkManager doesn't abruptly disrupt the network mid-install.) I am *not* suggesting that a prerequisite would be any kind of *full* integration with networkd that allows NM to meaningfully configure it. I'm suggesting that, with systemd-networkd installed and managing some interfaces, installing NetworkManager should not touch those interfaces in any way. (Ideally, NM guis would also give some indication of "you might want to remove the networkd configuration if you want NM to manage these interfaces, such as automatically switching between wired and wireless".) Apart from that, +1 for the plan of choosing between networkd and NetworkManager, and *not* introducing any layer of indirection. The primary point of NetworkManager is to support its management/configuration GUIs, so we *especially* shouldn't have a layer of indirection that doesn't treat the GUI-based configuration as primary.
