dhcpcd5 update broken in bullseye Raspberry Pi OS?

[dpc]

I have two bullseye Raspberry Pi OS and the dhcpcd5 update just installed seems to break DHCP, which means my Pi's are no longer visible on network after a reboot.

Code: Select all

Linux rpif2 5.10.60-v8+ #1449 SMP PREEMPT Wed Aug 25 15:01:33 BST 2021 aarch64 GNU/Linux

When I tried to manually restart service (before a reboot), here is the from log (pertinent error copied again next):

dhcpcd.service: Failed at step EXEC spawning /usr/lib/dhcpcd5/dhcpcd: No such file or directory

Code: Select all

sudo journalctl -u dhcpcd
...
Sep 25 17:34:30 rpif2 dhcpcd[555]: eth0: no IPv6 Routers available
Sep 27 10:17:00 rpif2 dhcpcd[555]: received SIGTERM, stopping
Sep 27 10:17:00 rpif2 dhcpcd[555]: eth0: removing interface
Sep 27 10:17:00 rpif2 systemd[1]: Stopping DHCP Client Daemon...
Sep 27 10:17:00 rpif2 dhcpcd[555]: dhcpcd exited
Sep 27 10:17:00 rpif2 systemd[1]: dhcpcd.service: Succeeded.
Sep 27 10:17:00 rpif2 systemd[1]: Stopped DHCP Client Daemon.
Sep 27 10:17:00 rpif2 systemd[1]: Starting DHCP Client Daemon...
Sep 27 10:17:00 rpif2 systemd[46789]: dhcpcd.service: Failed to locate executable /usr/lib/dhcpcd5/dhcpcd: No such file or directory
Sep 27 10:17:00 rpif2 systemd[46789]: dhcpcd.service: Failed at step EXEC spawning /usr/lib/dhcpcd5/dhcpcd: No such file or directory
Sep 27 10:17:00 rpif2 systemd[1]: dhcpcd.service: Control process exited, code=exited, status=203/EXEC
Sep 27 10:17:00 rpif2 systemd[1]: dhcpcd.service: Failed with result 'exit-code'.
Sep 27 10:17:00 rpif2 systemd[1]: Failed to start DHCP Client Daemon.
Sep 27 10:17:01 rpif2 systemd[1]: dhcpcd.service: Scheduled restart job, restart counter is at 1.

from the apt upgrade output:

Code: Select all

Unpacking dhcpcd5 (1:8.1.2-1+rpt2) over (1:8.1.2-1+rpt1) ...
dpkg: warning: unable to delete old directory '/var/lib/dhcpcd5': Directory not empty
...
Setting up dhcpcd5 (1:8.1.2-1+rpt2) ...
Installing new version of config file /etc/init.d/dhcpcd ...
update-alternatives: warning: alternative /sbin/dhcpcd5 (part of link group dhcpcd) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/dhcpcd is dangling; it will be updated with best choice

what does dhcpcd5 package contain in /sbin:

Code: Select all

dpkg -L dhcpcd5 | grep /sbin
/usr/sbin
/usr/sbin/dhcpcd

From the package changelog:

Code: Select all

sudo apt changelog dhcpcd5
Get:1 store: dhcpcd5 1:8.1.2-1+rpt2 Changelog
Fetched 7,196 B in 0s (484 kB/s)

dhcpcd5 (1:8.1.2-1+rpt2) bullseye; urgency=medium

  * New upstream version 8.1.2
  * Install dhcpcd's wpa_supplicant hook
  * Add netdev group and give it write access to dhcpcd.conf
  * Background dhcpcd on launch to avoid startup delays
  * Remove upstreamed patches
  * Use hardware address instead of duid for Client ID
    - https://github.com/raspberrypi/noobs/issues/336
  * Disable address senitisation

 -- Serge Schneider <serge@raspberrypi.com>  Wed, 22 Sep 2021 17:48:34 +0100

dhcpcd5 (7.1.0-2) unstable; urgency=high

<<snip>>

 -- Scott Leggett <scott@sl.id.au>  Sun, 05 May 2019 21:55:14 +0800

[dpc]

the error message for /usr/lib/dhcpcd5/dhcpcd apparently originates from

/etc/systemd/system/dhcpcd.service.d/wait.conf

I do not know which package owns this file.

Code: Select all

cat /etc/systemd/system/dhcpcd.service.d/wait.conf
[Service]
ExecStart=
ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -w

I have tried to change the exec path in that file to /usr/sbin/dhcpcd but it does not appear to work?

Code: Select all

[Service]
ExecStart=
ExecStart=/usr/sbin/dhcpcd -q -w

after editting

Code: Select all

sudo systemctl daemon-reload
sudo systemctl restart dhcpcd.service
sudo systemctl status dhcpcd.service

with the error in log output

Code: Select all

Sep 27 11:08:32 rpif2 systemd[1]: dhcpcd.service: Scheduled restart job, restart counter is at 5.
Sep 27 11:08:32 rpif2 systemd[1]: Stopped DHCP Client Daemon.
Sep 27 11:08:32 rpif2 systemd[1]: dhcpcd.service: Start request repeated too quickly.
Sep 27 11:08:32 rpif2 systemd[1]: dhcpcd.service: Failed with result 'start-limit-hit'.
Sep 27 11:08:32 rpif2 systemd[1]: Failed to start DHCP Client Daemon.

[dpc]

After a reboot, having changed the contents of /etc/systemd/system/dhcpcd.service.d/wait.conf to

Code: Select all

[Service]
ExecStart=
ExecStart=/usr/sbin/dhcpcd -q -w

(note the path to the executable having been updated) seems to now allow DHCP to get an IPv4 address again.

One new issue now observed is that "Predictable" network interface names, e.g., eth0 is NOW broken on this system, with the raspi-config Advanced Options > Network Interface Names having no effect when enabled.

the error message for /usr/lib/dhcpcd5/dhcpcd apparently originates from

/etc/systemd/system/dhcpcd.service.d/wait.conf

I do not know which package owns this file.

Code: Select all

cat /etc/systemd/system/dhcpcd.service.d/wait.conf
[Service]
ExecStart=
ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -w

Code: Select all

sudo systemctl daemon-reload

[ShiftPlusOne]

No package owns that file. It's added by raspi-config if you use the 'wait for network' option. Try disabling and re-enabling that option, which I believe should make it work if your raspi-config package is up to date.

[dpc]

I toggled the 'wait for network' option using raspi-config and the contents of /etc/systemd/system/dhcpcd.service.d/wait.conf were almost identical to my WORKAROUND edit listed above, and it has the same outcome of DHCP functioning.

Code: Select all

cat /etc/systemd/system/dhcpcd.service.d/wait.conf
[Service]
ExecStart=
ExecStart=/usr/sbin/dhcpcd -w

Code: Select all

ExecStart=/usr/sbin/dhcpcd  -w
# vs.
ExecStart=/usr/sbin/dhcpcd -q -w

this current dhcpcd5 update via an `apt upgrade` is likely to break any systems which use DHCP for IP assignment without additional interventions, as that setting of 'wait for network' option is the default in the Raspberry Pi OS images (bullseye lite and 64-bit bullseye),

Also, the raspi-config for "predictable network i/f names" is still broken with this update.

raspi-config Advanced Options > Network Interface Names

• Network Interface Names
• > Enable/disable predictable network i/f names

No package owns that file. It's added by raspi-config if you use the 'wait for network' option. Try disabling and re-enabling that option, which I believe should make it work if your raspi-config package is up to date.

[dpc]

Also, the raspi-config for "predictable network i/f names" is still broken with this update.

raspi-config Advanced Options > Network Interface Names

• Network Interface Names
• > Enable/disable predictable network i/f names

I just wanted to follow up to confirm that toggling this option (to have the desired predictable net I/F names like `eth0` , etc.) and rebooting has no effect on the interface names displayed by `ifconfig`.

the I/F names are still something like enxb827eb735881

[ShiftPlusOne]

There's some confusing terminology about 'predictable' interface names. What some people consider to be 'predictable' isn't exactly what systemd's developers meants.

What exactly are you expecting and what exactly are you seeing?

[ShiftPlusOne]

Also to note, we haven't released bullseye nor do we recommend upgrading to bullseye. There are things we know are broken and things that will continue to be broken unless you start with a clean image (once it's released)

I will make an exception for this case and make it possible to upgrade dhcpcd5 without that option breaking, since breaking the network on update is worse than the usual "you might have a few issues".

[Milliways]

Also, the raspi-config for "predictable network i/f names" is still broken with this update.

It is possible to restore eth0 etc with the option net.ifnames=0 in cmdline.txt

[ShiftPlusOne]

Also, the raspi-config for "predictable network i/f names" is still broken with this update.

It is possible to restore eth0 etc with the option net.ifnames=0 in cmdline.txt

Shouldn't be necessary with the latest bullseye version of raspi-config.

[ShiftPlusOne]

Seeing some issues with interface names as well now. Looking into it.

EDIT: False alarm, it's working as expected here.

[ShiftPlusOne]

Updated raspberrypi-sys-mods to automatically fix wait.conf and (un-)predictable interface names on upgrade.

[semitones]

This happened to me as well. I first turned toggled systemd's predictable names back "off" (I had turned them on a while ago), and then deleted wait.conf, seems to work fine.

[dpc]

I had internalized the wrong polarity of what "enabled" means for predictable network names. I think the correct meaning for this raspi-config setting is as follows (stating my new assumptions in case they are incorrect):

• enabled: use HW MAC and other HW components to form I/F name (e.g. `enxb827eb735881`)
• not enabled: use familiar short names such as `eth0`, `eth1`, etc. but they may not map same ordinal number to same device across reboots

Anyway, I didn't have an "un-upgraded" bullseye machine to test the new raspberrypi-sys-mods, raspi-config packages on.

On an already "upgraded" bullseye machine with workarounds in place, things continued working as they were supposed to after most recent `apt upgrade`, including across reboots (output follows):

Code: Select all

Get:1 http://archive.raspberrypi.org/debian bullseye/main armhf raspberrypi-sys-mods armhf 20210928 [11.8 kB]
Get:2 http://archive.raspberrypi.org/debian bullseye/main armhf raspi-config all 20210927 [29.1 kB]
Fetched 40.9 kB in 0s (93.6 kB/s)  
Reading changelogs... Done
(Reading database ... 55668 files and directories currently installed.)
Preparing to unpack .../raspberrypi-sys-mods_20210928_armhf.deb ...
Unpacking raspberrypi-sys-mods (20210928) over (20210901) ...
Preparing to unpack .../raspi-config_20210927_all.deb ...
Unpacking raspi-config (20210927) over (20210924) ...
Setting up raspberrypi-sys-mods (20210928) ...
Fixing previous dhcpcd wait.conf drop-in...
Setting up raspi-config (20210927) ...

Updated raspberrypi-sys-mods to automatically fix wait.conf and (un-)predictable interface names on upgrade.

[Andal]

dhcpcd.service: Failed at step EXEC spawning /usr/lib/dhcpcd5/dhcpcd: No such file or directory

I got this error after upgrading today from buster.
Seems to be still broken?

[T_N_T]

I've a headless Pi (no keyboard/mouse/monitor, only SSH). Got this error after Bullseye upgrade, connected it to a TV and dropped here.

I've only changed /etc/systemd/system/dhcpcd.service.d/wait.conf using the sdcard on another computer

from:

Code: Select all

[Service]
ExecStart=
ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -w

to:

Code: Select all

[Service]
ExecStart=
ExecStart=/usr/sbin/dhcpcd -q -w

And it's back on business. Thanks a lot!

[abrax5]

Thanks, @dpd, editing the service file to fix the path worked for me after upgrading a Pi Zero W 2.

[jplegat]

I've a headless Pi (no keyboard/mouse/monitor, only SSH). Got this error after Bullseye upgrade, connected it to a TV and dropped here.

I've only changed /etc/systemd/system/dhcpcd.service.d/wait.conf using the sdcard on another computer

from:

Code: Select all

[Service]
ExecStart=
ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -w

to:

Code: Select all

[Service]
ExecStart=
ExecStart=/usr/sbin/dhcpcd -q -w

And it's back on business. Thanks a lot!

Thanks a lot! It did work.

[beta-L-user]

Unfortunately I have the same problem (and some more), but the directory dhcpcd.service.d including wait.conf-file does not exist.
I always had static IP-addresses defined in dhcpcd.conf. After bullseye-upgrade there was an dhcp-assigned IP-address only.

After several trials I tried

Code: Select all

sudo dhcpcd -g 
sudo dhcpcd -k

and it worked then.

It came with other strange behaviours after the bullseye upgrade:
- WiFi does not start automatically after reboot (which is annoying if you need remote access) - in any case - at all Raspberry Pis
- after fixing the static IP-address issue I have both: dhcp-assigned AND the static IP-address
- it seems that IP6-addresses cannot be suppressed by noipv6

In one case of an Raspberry Pi 3 B the wait.conf file was created when I did the above mentioned commands, with a Raspberry Pi zero no wait.conf is present since I used the commands but it worked as well.

Therefore I think that another daemon is running parallel.

hope it helps
beta-L-user