dhcpcd is installed (and enabled by its package's default preset) in the
raspberrypi/debian/ubuntu/proxmox molecule images to mimic each distro'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 minute or two of container boot — fast enough to break
DNS resolution for apt-get tasks later in the same converge run.
Reproduced and confirmed on all four affected scenarios (raspberrypi,
debian, ubuntu, proxmox — each installs dhcpcd the same way): apt-get
tasks failed with repeated "Temporary failure resolving" errors at
varying points in the play depending on timing. archlinux/archlinux-gnome
and git (Alpine) don't install dhcpcd and are unaffected.
The network role already intends to remove dhcpcd/avahi-daemon entirely
(replacing them with NetworkManager/systemd-resolved), but that removal
task runs after earlier package-install steps — so the very service
being phased out was sabotaging tasks that ran before it got purged.
Masking dhcpcd.service at image-build time prevents it from ever running
in these test containers, closing the race without touching any role's
actual task order or logic (which reflects real hardware, where dhcpcd
does get a valid lease from an actual router).
Co-Authored-By: Claude.ai