I followed the official guide and it works perfectly for an rPi3 running on buster but fails on an rPi4 running on buster-lite and I can't see why/I can't see the difference.

The problem: In contrast to the rPi3/buster the eth0 is not added to the bridge br0. eth0 receives an ip-address from the DHCP-server instead of the bridge br0. Somehow the denyinterface for eth0 in dhcpcd.conf is ignored. According to journalctl -u dhcpcd br0 aquires a weird ip-address.

... dhcpcd[712]: br0: probing for an IPv4LL address
... dhcpcd[712]: br0: using IPv4LL address

According to dmesg eth0 is not added to the bridge br0 on port 1. In contrast, on the rPi3 eth0 is added to the brigde on port 1 and wlan0 on port 2.

Q What am I missing?

Note On buster-lite I had to manually install dhcpcd5.

Update 1 rPi4

$ cat /etc/os-release 
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"

$ apt search dhcpcd
dhcpcd5/testing,now 1:8.1.2-1+rpt1 armhf [installed]
  DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support

The rPi3 had dhcpcd5 installed out of the box

$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"

$ sudo apt search dhcpcd
dhcpcd5/testing,now 1:8.1.2-1+rpt1 armhf [installed]
DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support

Update 2 This hit me hard and unexpected: On top of raspbian-buster I installed openmediavault (OMV).

The OMV installation injects

$ cat /run/systemd/network/10-netplan-eth0.network



and this file is breaking my bridge.

The rule-file is generated by /etc/netplan/20-openmediavault-eth0.yaml

Q1 How can this be fixed properly?


3 Answers 3


First: calling it dhcpcd5 may create confusion (esp for me :) because of the history of dhcpcd. Yes - the executable file is named dhcpcd5, but it's generally referred to as dhcpcd. man dhcpcd is the same file as man dhcpcd5, and (as @Milliways pointed out in a comment) dhcpcd is a link to dhcpcd5. If you have dhcpcd5 - you have dhcpcd. Here's where I first learned of this.

Second: RPi OS Lite comes with dhcpcd (aka dhcpcd5) already installed - and even a /etc/dhcpcd.conf that works on almost all networks immediately and without editing.

If you don't have dhcpcd installed, then something odd may have happened to your system. You may have un-installed it with a systemd-networkd installation? If you didn't uninstall it (and that doesn't appear to be the case), then I'd suggest you start over - do a fresh install of buster lite on your SD card.


You've edited your question, and it seems that you do have dhcpcd/dhcpcd5 installed as it should be. Unless you've edited the default /etc/dhcpcd-conf, I think this is as it should be.

I've not tried the procedure you referenced, and I'm not in a position to try that now. The possibilities that present themselves immediately are 1) the procedure is flawed, 2) you've made a mis-step in executing it on the RPi4, or 3) there is a hardware or firmware diff between the RPi3 & RPi4 that is responsible.

I'll need to come back to this as I've run out of time for the present. The only other thought would be to look further into the possibility of a firmware-induced cause... for that, I'd post an "issue" (a question actually) to the rpi-eeprom github repo.

  • @Milliways: Whoops! :) Thanks - I'll fix this shortly.
    – Seamus
    Commented Dec 22, 2020 at 1:30

Q1 How can this be fixed properly?

If you actually read the documentation for the software you installed (preferably BEFORE installing) it would have told you it uses systemd-networkd for networking.

The logs would have shown that OMV DELETES dhcpcd.

Then set networking to use systemd-networkd rather than a different system (dhcpcd)

  • Which log shows the deletion of dhcpcd? Commented Dec 23, 2020 at 11:02

As @Milliways pointed out, openmediavault (OMV) disables dhcpcd. Therefore, I doctored a netplan-yaml-file which I found on the net and it seems to do the trick:

$ cat 30-bridge.yaml 
        macaddress: dd:aa:33:dd:00:aa
      #accept-ra: true
      dhcp4: false
      dhcp6: false

      interfaces: [eth0]
      #addresses: []
      gateway4: 192.168.x.x
      mtu: 1500
        addresses: [192.168.x.x]
        stp: true
        forward-delay: 4
      dhcp4: true
      dhcp6: true
      accept-ra: true

Any improvements to the netplan-yaml-file are highly appreciated.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.