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? regards -mika-
signature.asc
Description: PGP signature
