| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
Co-Authored-By: Claude.ai
|
|
|
|
|
|
|
|
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
|
|
domain = {{ pihole_domain }} rendered as an unquoted bareword containing
a dot (e.g. "pi.hole"), which is invalid TOML. TOML parsing is
all-or-nothing, not line-by-line, so pihole-FTL rejected the entire
config file on that one line and silently fell back to its compiled-in
defaults — including binding its webserver directly to ports 80/443.
That collided with caddy, which wants the same ports, causing caddy to
crash-loop and get reported as "changed" (needing a restart) on every
subsequent ansible run.
Quoting the domain value lets the file parse successfully, which in turn
surfaces a second, previously-unreachable bug: the custom webserver port
(pihole_port) was rendered as a bare number, but Pi-hole v6 FTL requires
each listener address to carry a trailing flag character (o = optional,
s = TLS). Without it FTL rejects the value the same way and reverts to
the 80/443 default. Appending "o" fixes that.
Both bugs had to be fixed together: the quoting bug was blocking the
parser from ever reaching the port line, so the port fix alone had no
effect until parsing succeeded end-to-end.
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
|
|
The APK approach never existed
AI made that up
Co-Authored-By: Claude.ai
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is refactoring the PoC for deploying cgit on pve, to now move to a
more standard deployment with dedicated agnonstic proxy role/container
|
|
|
|
|
|
|
|
|
|
Co-Authored-By: Claude.ai
|
|
Co-Authored-By: Claude.ai
|
|
This to make the role have less configurations, and less prune to human
errors
|
|
Since this role has never worked properly, this state with updating the
resolution and keeping the nouveau driver working with acceptable
performance on external monitors
|
|
|
|
Since the mac driver is still broken when connected to external
monitors, this is yet another attempt at fixing the pleasantly
apple quirky wifi and graphics to work on linux!
|
|
|
|
|
