On October 14, 2025 8:23 am, Michael Prokop wrote: > Hi, > > * Fabian Grünbichler [Mon Oct 13, 2025 at 11:00:52AM +0200]: >> On October 9, 2025 8:20 pm, Michael Prokop wrote: > >> > The system went into production usage already, but now when thinking >> > about what happened and looking at my docs, I recalled that when one >> > switches from ifupdown to ifupdown2 and then purges the ifupdown >> > package, the networking.service goes missing. >> > >> > Demonstration in a trixie podman container: >> > >> > [..] >> >> > And looking at my own customer documentation, I also found the >> > reference for this problem in the Proxmox BTS: >> > https://bugzilla.proxmox.com/show_bug.cgi?id=2950 :) >> >> ha :) > > :) > >> so yeah, I think this would require coordination between >> >> - ifupdown >> - ifupdown2 >> - ifupdown-ng (which doesn't currently manage networking.service, so is >> only affected when being switched to, but doesn't cause the problem >> itself); >> >> in order to avoid the disable call to systemctl in case of purge, if >> another implementation providing networking.service is still around.. > > ACK. FTR, I also verified it on the production system, with > ifupdown2 being present (v3.3.0-1+pmx10) and ifupdown removed, but > not yet purged. The workaround was: > > sudo dpkg --purge ifupdown > sudo systemctl enable networking > > Then it continues to work as expected. > >> AFAICT, this would require quite ugly handling (effectively overriding >> the systemd dh call, copying the maintainer script code it would have >> generated, but adding another guard for networking.service being >> around?). >> >> in any case, switching to ifupdown2 can only be fixed in ifupdown (and >> vice-versa). > > ACK. What *might* help as a workaround could be a check within > ifupdown2's maintainer scripts for a *removed* but not yet *purged* > ifupdown package. Then it could provide a warning and instructions > how to fix this. This might help users who are not aware of this > issue, at least until it's properly handled between > ifupdown/ifupdown2 without requiring manual intervention?
https://salsa.debian.org/debian/ifupdown-ng/-/commit/fad9af1f6ec26f592ac056d5497f269c7f6d28bc is what Daniel (the ifupdown-ng maintainer) came up with yesterday after a short chat. it's a bit of a hack, and relies on the fact that the Debian systemctl wrappers don't actually call `systemctl disable foo` (which would again disable the real service as well, and not just networking.service), but clean up the links manually without accounting for aliasing, but it seems to work as a stop-gap measure. it also of course still leaves `networking.service` (now an alias) disabled, which might mean breaking custom integration relying on that name being used, so it's only a partial solution in any case. we'd either need to adapt the integration/wrappers to handle multiple owners of a unit name correctly, or override them to get a complete fix...
