dhcpcd is installed (and enabled by its package's default preset) in the
test container to mimic Raspberry Pi OS's default boot environment. Inside
podman's virtual network there's no real DHCP server for it to negotiate
with, so it only ever gets a link-local address and overwrites
/etc/resolv.conf with an empty file (just dhcpcd's template comments, no
nameserver line). This happens within the first ~1-2 minutes of container
boot, which is fast enough to break DNS resolution for later apt-get
tasks in the same converge run — observed failing on "network : Ensure
network_packages are installed" with repeated "Temporary failure
resolving 'deb.debian.org'".
The network role already intends to remove dhcpcd/avahi-daemon entirely
(replacing them with NetworkManager/systemd-resolved), but that removal
task runs after the package-install step that was failing — so the very
service being phased out was sabotaging the install of its replacement.
Masking dhcpcd.service at image-build time prevents it from ever running
in the test container, closing the race without touching the network
role's actual task order or logic (which reflects real hardware, where
dhcpcd does get a valid lease from an actual router).
Confidence in this is medium
Co-Authored-By: Claude.ai