> 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


You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.

  forced use of systemd-networkd interferes with ifupdown in 18.04

Status in ifupdown package in Ubuntu:
Status in systemd package in Ubuntu:

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

  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.


To manage notifications about this bug go to:

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

Reply via email to