Co-Authored-By: Claude.ai

pacman 7.0+'s alpm sandbox runs package download/extraction under a
restricted user + seccomp filter. That filter needs syscalls QEMU's
user-mode emulation doesn't support, so building this amd64 image on an
arm64 host (e.g. Apple Silicon) fails immediately on the first pacman
call:

    error: error restricting syscalls via seccomp: 22!
    error: switching to sandbox user 'alpm' failed!

Confirmed directly: `pacman -Sy` fails with the sandbox enabled and
succeeds cleanly with `DisableSandbox` set in pacman.conf.

Scoped entirely to this test image, not any real role/target this repo
manages. Safe for CI too — the sandbox is a defense-in-depth layer
protecting the host from a compromised download during package fetch,
irrelevant to a container that's destroyed immediately after each test
run; disabling it changes no package-resolution or install behavior,
only removes that extra isolation layer. Native (non-emulated) CI
runners were never affected by the underlying bug either way.

Co-Authored-By: Claude.ai

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

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

Co-Authored-By: Claude.ai