Patch_10_2 dhclient→udhcpc migration breaks networking on Trixie devices using ifupdown2

[InnovoDeveloper]

Creating a bug report/issue

• I have searched the existing open and closed issues

Required Information

• DietPi version | G_DIETPI_VERSION_CORE=10, G_DIETPI_VERSION_SUB=2, G_DIETPI_VERSION_RC=3 (v10.2.3)
• Distro version | trixie (Debian 13)
• Kernel version | Linux MagicCubeAura 6.18.16-current-rockchip64 #1 SMP PREEMPT Wed Mar 4 12:25:12 UTC 2026 aarch64 GNU/Linux
• SBC model | NanoPi R5C (aarch64) — but this affects any DietPi Trixie device using ifupdown2 + DHCP
• Power supply used | 5V 3A USB-C (official)
• SD card used | eMMC module (32GB)

Additional Information

• Software title | ifupdown2 (3.0.0-1.3), udhcpc (1:1.37.0-6)
• Was the software title installed freshly or updated/migrated? | Updated from DietPi 10.1 to 10.2.3 via dietpi-update
• Can this issue be replicated on a fresh installation of DietPi? | Yes — any Trixie device with iface ethX inet dhcp in /etc/network/interfaces and ifupdown2 installed
• Bug report ID | 78ef9600-b193-400f-be59-fdded054ccc9

Steps to reproduce

1. Start with a DietPi Trixie device running v10.1.x with ifupdown2 and isc-dhcp-client installed
2. /etc/network/interfaces has iface eth0 inet dhcp
3. Run dietpi-update to update to v10.2.x
4. The Patch_10_2() function in .update/patches runs:

   G_AGI udhcpc
   G_EXEC apt-mark auto isc-dhcp-client

5. Later in the update, G_AGP (autopurge) runs and removes isc-dhcp-client, deleting /sbin/dhclient
6. Reboot the device
7. networking.service fails — device has no IP, unreachable via SSH

Expected behaviour

After dietpi-update migrates from isc-dhcp-client to udhcpc, networking should continue to work on reboot. Either:

• ifupdown2 should be patched to support udhcpc as a DHCP client, or
• isc-dhcp-client should not be autopurged on systems running ifupdown2 until ifupdown2 has udhcpc support

Actual behaviour

On reboot after the update, networking.service (ifupdown2) fails with:

eth0: cmd '/sbin/dhclient -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0'
failed (Errno 2) No such file or directory: '/sbin/dhclient'

The device gets no IP address and is completely unreachable over the network. For headless/remote devices, this requires physical console access to recover.

Extra details

Root cause analysis:

ifupdown2 v3.0.0 has /sbin/dhclient hardcoded in every method of /usr/share/ifupdown2/ifupdownaddons/dhclient.py (start, stop, release, start6, stop6, release6). There is no configuration option to select a different DHCP client and no fallback mechanism. When isc-dhcp-client is removed, every DHCP operation fails with ENOENT.

The Patch_10_2() function installs udhcpc and marks isc-dhcp-client as auto-removable, but does not check whether the installed networking stack (ifupdown2) is compatible with udhcpc. ifupdown2 has zero support for udhcpc — it is entirely different from classic ifupdown, which can use pluggable DHCP client scripts.

Related upstream issues:

• Debian Bug #1106121 — isc-dhcp EOL, lists ifupdown2 as affected
• ifupdown2 PR #253 — Adds multi-DHCP-client support (udhcpc), open since Feb 2023, never merged
• Proxmox forums report the same ifupdown2 + missing dhclient failure on Proxmox 9.x

The fix should be one of:

1. Guard Patch_10_2() — do not mark isc-dhcp-client as auto-removable if ifupdown2 is installed:

   if dpkg-query -l | grep -q '^ii[[:blank:]]*isc-dhcp-client[[:blank:]:]'
   then
       G_AGI udhcpc
       # Only allow autopurge if ifupdown2 is NOT installed
       if ! dpkg-query -W -f='${Status}' ifupdown2 2>/dev/null | grep -q 'ok installed'
       then
           G_EXEC apt-mark auto isc-dhcp-client
       fi
   fi

2. Or deploy a dhclient→udhcpc shim at /sbin/dhclient that translates dhclient CLI arguments to udhcpc equivalents (this is what we implemented as a workaround — happy to share the shim script)

3. Or patch ifupdown2 to support udhcpc natively (per the stalled PR Support IQaudIO DACs #253)

Workaround (for affected users):
If your device is already bricked after update, connect via serial/console and run:

ip link set eth0 up
udhcpc -i eth0

Then either reinstall isc-dhcp-client (apt install isc-dhcp-client) or deploy a /sbin/dhclient wrapper that calls udhcpc.

apt history confirming the sequence:

Start-Date: 2026-03-23  14:15:43
Commandline: apt-get -y --allow-change-held-packages install udhcpc
Install: busybox:arm64 (1:1.37.0-6+b7, automatic), udhcpc:arm64 (1:1.37.0-6)
End-Date: 2026-03-23  14:16:08

Start-Date: 2026-03-23  14:16:40
Commandline: apt-get -y autopurge
Purge: isc-dhcp-client:arm64 (4.4.3-P1-8)
End-Date: 2026-03-23  14:16:42

journalctl output after reboot (networking.service failure):

eth0: cmd '/sbin/dhclient -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0'
failed ([Errno 2] No such file or directory: '/sbin/dhclient')

[MichaIng]

Um, does ifupdown2 support dhclient only? So then it is dead with Forky?

Anyway, makes sense to not enforce the migration in this case. I wonder whether we should do it the other way round: install udhcpc and purge isc-dhcp-client only if ifupdown is installed? ifupdown2 has a conflict on it, so this is implied if ifupdown2 is installed, and other network setups might depend on isc-dhcp-client as well.

EDIT: There is a PR upstream to add dhcpcd support. Let's see whether it gets merged in time before Forky freeze: CumulusNetworks/ifupdown2#347

[MichaIng]

Fixed with: 02a5a39
And backported to master: 907b687
Hence the update to DietPi v10.2 can now be applied without this regression.

[speedingcheetah]

Not sure of this is the same or related to both my DietPi systems (a Intel PC running Trixe and a Pi4b running Bookworm) updated to 10.2.3 and upon reboot, NIC fails to connect.
It hangs for a tad at "Job ifup@eth1.service/start running".
Then FAILED to start ifup@eth1.service - if up for eth1.
Then finishes bootup, and gets that default ip address when there is no connection.
When i went into dietpi-config and did anything in Adapter setting, and restarted Networking, DHCP worked. But, fails again after reboot/power cycle.
Had to set device to static in dietpi-config, and that results in the NIC connection working after reboot.
But, DHCP seems broken at boot.

[miloit]

Is there a manual way to patch my bricked device?

[Joulinar]

I guess you would need to gain local access via debug uart terminal or local console. Another option might be to connect your storage device to another Linux box and set a static IP into the configuration files.

[MichaIng]

Everyone who does NOT use ifupdown2, but has issues with DHCP on boot after the update, see here: #8039 (comment)

The issue here is only about ifupdown2, which does not support dhcpcd either, hence needs to keep dhclient/isc-dhcp-client. Both issues are fixed in our updater, but if you updated earlier, and udhcpc was installed already, it needs to be applied manually.

[InnovoDeveloper]

Fixed with: 02a5a39 And backported to master: 907b687 Hence the update to DietPi v10.2 can now be applied without this regression.

This works. Thank you!