initrd starts dhclient on interfaces that are not supposed to get an IP address

[Valentijn Sessink]

After trying several setups, I think this is a bug. If not - I can't find how to fix things.

Setup: Ubuntu 22.04, with ubuntu-minimal installed (which depends on isc-dhcp-client). A network with a bridge interface. This can be anything, even an old /etc/network/interfaces file will do. For simplicity, the following netplan setup is used:

network:
    version: 2
    ethernets:
        enp4s0:
          wakeonlan: true
            dhcp4: no
            dhcp6: no
    bridges:
      br0:
        interfaces: [enp4s0]
        dhcp4: yes
        dhcp6: yes
        parameters:
          stp: false
          forward-delay: 0

What happens:
Starting this machine will, during initrd phase, make dhclient fetch an IP address for enp4s0. Then netplan takes over and fetches an address for br0. If both enp4s0 and br0 have the same IP address from the DHCP-server, the machine will not be reachable.

What should happen:
enp4s0 should not get an IP address, as the netplan-configuration clearly says.

A workaround is to remove isc-dhcp-client (which, in turn, removes meta-package ubuntu-minimal) and run update-initramfs -k all -u; afterwards, the dhclient in initrd is (obviously) not there anymore.

[Benjamin Drung (bdrung)]

Can you specify how you boot your system? Which parameters do you pass to the kernel?

Do you need IP configuration in your initrd? Otherwise you can drop the ip= or ip6= parameter from the kernel command line.

[Valentijn Sessink (valentijn)]

It's not any cmdline options. (/proc/cmdline has root=[rootdev] ro)

But I searched on because I couldn't reproduce this bug on a virtual machine. While on the host system that bugged me, a change in /usr/share/initramfs-tools/scripts/functions to not start dhclient (but echo it instead to a file somewhere) showed that the bug was still there.

Turns out: installing aoetools is the culprit:
apt-get install aoetools
update-initramfs -k all -u

Skimming through local-top/aoe briefly, I can't see where this goes wrong. Both iscsi and nfs seem to have the same "configure_networking" settings. But I'm probably missing something, as I'm not 100% at home in initrd scripts.

[Valentijn Sessink (valentijn)]

Maybe the bug now should be filed against aoetools? That's in universe, so maybe it should even be closed as "invalid"?

[Benjamin Drung (bdrung)]

No, aoetools is not at fault here. The initrd does not take your netplan configuration into account. You could specify the ip= kernel parameter to let the initrd setup your network as you want it, but initramfs-tools does not have any support for brigdes as far as I know.

If you do not need/use aoetools, then you can just remove that package or specify "ip=off" on the kernel command line to disable configuring the network in the initrd.

[Valentijn Sessink (valentijn)]

ip=off helps, thanks.

If initramfs-tools doesn't do bridges and this is the result, then that's a bug. Although I admit it's probably quite an uncommon setup :-/

[Lukas Märdian (slyon)]

Right. The handover from basic networking in initrd to the full Netplan setup in the booting/booted system could probably be improved (in may ways), e.g. flushing the IP addresses.

I guess that's something we'd need to implement in systemd-networkd when taking over the interfaces. I wonder if NetworkManager is handling this situation any different here? Did you try installing the "network-manager" package and using the global "renderer: NetworkManager" setting in your Netplan configuration? Does it show the same result?