> A simple "apt install ifupdown" will not undo everything that installer has done to setup the system, nor redo it for the alternative networking management tool. Where do you expect ifupdown configs to materialize from?
Well that's kind of my point - your documentation is deficient around that. And we expect the ifupdown configuration to 'materialize' from the sysadmin writing them, that's the point of ifupdown isn't it? I'd wager that anyone reverting to ifupdown is doing so specifically because they don't want something managing configuration for them - they want to do it themselves. > Given that the system is sensitive to all configs present on disk. This is > similar situation to how on the desktop one cannot simply "remove > network-manager & install ifupdown" to switch to ifupdown. That's why we tried disabling systemd-networkd, which came back as enabled on subsequent boots. Apparently netplan adds some hooks that aren't clearly documented (at least when I looked on netplan.io, maybe I missed them?). I guess netplan needs to be actively purged, but that breaks the dep on it in ubuntu-minimal which may not be desirable to purge if its dep list changes in the future and people want to pull in those deps (apart from netplan). > can you please give the examples that you have experienced, specifically? the > ubuntu developers have gone extensive amount of porting, and integration > testing to ensure that as many things as possible are fixed to work, both on > new installs and upgrades. We run gateways and firewalls with multiple providers and so forth. The need for pre-up, and more importantly post-up, comes up frequently in all sorts of situations. 'We need to (re)start openvpn after this vlan interface is configured, but both need to happen only after this pppoe interface is (re)configured' (yeah some of our ISPs still use ppp.. even on fibre links. it's terrible). This is why systemd-networkd implements such a facility, and why ifupdown does too. I feel it's near-sighted of netplan to pretend the need doesn't exist when the things it's configuring do see the need and do implement such facilities. If Ubuntu devs tested netplan extensively' I'd wager they never tested beyond basic use cases otherwise the deficiency would have been obvious. There are other, complex configurations out in the wild and netplan can't even begin to accommodate them in its current form. Which is fine... we remove it. But removing it appears to be problematic, or not permanent. So what's the correct method? Remove the initial config the installer makes? Does that let systemd-networkd remain disabled or does it get re-enabled anyway? Can you put this somewhere in the documentation and /etc/network/interfaces comments beyond the mere 'apt install ifupdown' that is there currently? As a side note we found an issue yesterday where DHCP via systemd-networkd in 18.04 wasn't working against an isc-dhcpd running on an early ubuntu version. The apparent inability to prevent systemd-networkd from trying to run and conflicting with other mechanisms was causing enough grief for my employer to decide to just give 18.04 a miss entirely. :( I could have put more time in to diagnosing it, or testing netplan with no config and purging the previous config from systemd-networkd and rebooting and hoping networkd didn't come back but it had already cost enough time by then and he made the call. > Please provide the contents of /etc/netplan on the affected systems, and > please let me know, if removing files in said directory makes networkd ignore > interfaces. I'll test this when I have a spare minute and report back soon Thanks, Wes -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1771236 Title: forced use of systemd-networkd interferes with ifupdown in 18.04 Status in ifupdown package in Ubuntu: Incomplete Status in systemd package in Ubuntu: Incomplete Bug description: For several reasons, we are not able to use netplan nor systemd- networkd due to legacy applications that expect ifupdown's pre-up and post-up script mechanism. The documentation around 18.04's (premature, I feel) wholesale adoption of netplan claims that one can revert to old behaviour by merely installing ifupdown (amongst assertions that netplan will never offer a mechanism for configuring pre-up and post-up actions even for network managers that support them). However when ifupdown is installed, systemd-networkd still tries to manage interfaces. If you 'systemctl disable systemd-networkd', upon next reboot it is automatically re-enabled. We tried disabling any systemd units even remotely related to networking and yet systemd- networkd still runs. If it hasn't been configured, it tries to DHCP. On networks that don't provide DHCP this results in a stupendously long stall during boot. Currently it appears to be impossible to tell systemd-networkd not to run in a clean manner that won't get reverted on package upgrades. I sincerely hope this is is a bug/oversight and not intentional. We need to be able to disable systemd-networkd properly. Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1771236/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
