summaryrefslogtreecommitdiffstats
path: root/roles/vim
diff options
context:
space:
mode:
authorAhmed Abdelhalim <[email protected]>2026-07-21 17:29:25 +0200
committerAhmed Abdelhalim <[email protected]>2026-07-21 17:29:25 +0200
commitca9887078e68a6ec02bce94a38db0c2d954c14ba (patch)
treecc56db5c1b15ad98dabcf9710e6bf436484ef087 /roles/vim
parent154f7318bfbeebc7eb2156f08c9ca5aa2d8ef774 (diff)
Mask dhcpcd in molecule images to fix DNS resolution failures
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
Diffstat (limited to 'roles/vim')
0 files changed, 0 insertions, 0 deletions