| Age | Commit message (Collapse) | Author | Files | Lines |
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is fixing the tmpfs mount point default mode 1777 to 0755
Co-authored-by: Claude.ai
|
|
|
|
Co-authored-by: Claude.ai
|
|
The timezone module was reading back the Etc/GMT instead of GMT, this
fixes the issue and avoid unnecessary code that needs to handle
different distro quirks (debian)
Fix grafana testing to use the URL
|
|
Refactor prometheus extra scraping jobs
|
|
|
|
|
|
This approach uses losetup to query the devices instead of flaky
unstable cache!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Now with the gpu_driver, the installing of the correct driver is
delegated to this role, which orchestrate the installing of one or more
drivers.
This refactoring of the role/testing, means that the roles don't run on
testing (intentionally), if a driver needs to be tested it will be added
but for now it's not really all that beneficial to keep this 30+ minutes
testing roles running just to test the packages existence.
It also simplifies the roles, and added as a dependency for steam which
is the main reason why these are needed to be installed (also better
hyprland animations, but that's not as crucial as steam failing without
the drivers).
|
|
|
|
|
|
|
|
Co-Authored-By: claude.ai
|