image-talos publishes with skopeo instead of buildx, so it never saw
--push=$(PUSH) and a local PUSH=0 build still overwrote talos tags in
REGISTRY.
Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Talos v1.14.2 ships DRBD 9.3.4 and ZFS 2.4.4. The v1.13 line tops
out at DRBD 9.3.3, which lacks the 9.3.4 fixes for a sender thread
pinning a CPU while its connection is down, for two-phase-commit
retries and hangs that leave drbdadm disconnect stuck, and for two
nodes ending UpToDate with different data after a reconnect.
Talos v1.14 no longer publishes ghcr.io/siderolabs/installer, so the
imager profiles take installer-base as the base installer, which is
also what upstream's own v1.14 imager profiles use.
BREAKING CHANGE: Talos v1.14 no longer loads kernel modules on demand,
so every node must list drbd_transport_tcp in machine.kernel.modules
before it is upgraded, or DRBD cannot connect to its peers.
Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>
The package pinned linux/amd64 because its assets were amd64 only.
With arm64 profiles it follows PLATFORM like every other image.
The installer is published as one index under every tag. skopeo
cannot assemble an index from the imager's docker archives, so the
archives go into one OCI layout and a small script writes the index
there for skopeo to push. buildx could build it from OCI layout
sources, but the release job builds on the classic docker driver,
which has no such source.
matchbox carries the kernel and initramfs of both arches whatever
PLATFORM is, rather than those of TARGETARCH: the node matchbox runs
on is not the arch of the machines it boots, so a per-arch image would
hand an amd64 machine an arm64 kernel whenever the pod lands on an
arm64 node. The amd64 assets stay at their old paths, and a group
keyed on the arch iPXE reports sends arm64 machines to the arm64 ones.
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Assisted-by: LLM
Cozystack runs on arm64 nodes, but the Talos assets it builds are
amd64 only, so arm64 clusters have to use an Image Factory schematic
instead of the cozystack build.
The arm64 profiles install drbd and zfs, which Cozystack needs, plus
the firmware of the PCIe NICs whose drivers the arm64 Talos kernel
carries. x86 CPU microcode is useless there, and the arm64 builds of
amdgpu and i915 are empty. The generator checks every listed extension
for a build of the target arch so an upstream change fails generation
rather than the imager. The amd64 profiles keep their names and
content.
Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>
PLATFORM defaulted to empty, so buildx built for the host alone. On an
arm64 workstation `make image` published an arm64-only digest, which
amd64 nodes then fail to pull; the cilium pin shipped exactly that
until it was rebuilt by hand. A build now targets linux/amd64 and
linux/arm64 unless PLATFORM is set, and the digest a package stamps is
the index digest.
LOAD=1 keeps building for the host only. The classic docker image store
cannot load a multi-platform index, and loading is the documented local
workflow.
This changes local pushes: a `make image` on the default docker driver
without the containerd image store now fails with "Multi-platform build
is not supported for the docker driver", where it used to build for
the host. Such a build needs a docker-container builder (BUILDER), or
LOAD=1 or an explicit PLATFORM for a single architecture.
talos and testing pin linux/amd64 with `override`, placed before the
include because common-envs.mk expands BUILDX_ARGS immediately. The
Talos assets are amd64: matchbox bakes the kernel and initramfs into
its image, and the e2e sandbox boots the disk under qemu-system-x86_64.
An arm64 variant of either would still serve or boot amd64 files.
CI pins linux/amd64 on every image build. Nothing there sets up QEMU,
fork builds export a single-platform archive, and tags.yaml builds on
the default docker driver, so the default would break or emulate those
jobs. Native arm64 builds belong in a leg of their own.
Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Belt-and-suspenders for the B2-class trap lexfrei flagged as latent in
image-tags. PUBLISH_* are 0 on fork PRs, so today the export path never emits a
versioned/floating tag — but if it ever did:
- image-tags: multiple --tag under `--output type=oci` write >1 manifest into
the archive's index.json, and `skopeo copy oci-archive:<f>` then refuses it
("more than one image in oci"). Suppress the versioned/floating tags when
OCI_EXPORT_DIR is set (macro-level $(if …), so `make -n` prints only the
taken branch).
- packages/core/talos: gate its versioned/floating `skopeo copy docker://…`
release copies on an empty OCI_EXPORT_DIR too.
The release (non-export) path is unchanged — versioned + :latest still emitted.
Covered by a new common-envs_test.bats case that forces PUBLISH_*=1 under
export.
Reported by gemini-code-assist on #3262.
Assisted-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
packages/core/talos `image-talos` pushed to the registry via `skopeo copy
docker://…` unconditionally — it is not a buildx call, so neither
OCI_EXPORT_DIR nor PUSH reached it. On a fork PR the registry login is
skipped, so this was an anonymous push that died with `denied`, collapsing
build-talos → finalize and the whole chain.
Under OCI_EXPORT_DIR, copy the installer to oci-archive:<dir>/talos.oci.tar
instead of pushing; keep the docker:// push otherwise. A make-level $(if …)
is used (not a shell if/else) so `make -n` prints only the taken branch.
Refs: #3257
Assisted-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Talos v1.13.5 ships Linux 6.18.36, which carries the fix for
CVE-2026-46113 but not the one for CVE-2026-53359. The two are related
KVM x86 shadow-paging bugs allowing a guest to escape to the host, and
both patches are needed for the mitigation to hold. Talos v1.13.6 ships
Linux 6.18.38, the first release on the 6.18 stable line that has both.
Profiles regenerated with hack/gen-profiles.sh v1.13.6. Alongside the
Talos version and the installer reference, this refreshes the pinned
system-extension digests: the firmware extensions move from the 20260519
to the 20260622 build, and intel-ucode stays on its 20260512 tag but
resolves to a new digest because upstream re-pushed that tag.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Refreshes the core/talos asset/profile layer onto current upstream to clear the
published advisories the scanner flagged in the stale pinned images.
- profiles: regenerated by hack/gen-profiles.sh v1.13.5, moving the base
installer and every system extension to the v1.13.5 line (installer v1.13.0 ->
v1.13.5; amdgpu/i915/drbd/zfs to their -v1.13.5 builds; amd-ucode and the
firmware blobs to the 20260519/20260512 snapshots). v1.13.5 rebuilds the
installer on the Go 1.26.4 toolchain and current runtime (kernel, containerd,
runc, OpenSSL), clearing the Go and libcrypto advisories compiled into the
stale v1.13.0 installer.
- matchbox: base image quay.io/poseidon/matchbox v0.10.0 -> v0.11.0, clearing
the libcrypto3 advisories in the matchbox runtime.
cozy-talos ships no runtime templates -- it drives the node image / installer /
matchbox asset builds. The Talos installer and matchbox images are rebuilt from
these sources by the release asset pipeline (the privileged imager build), which
also re-pins the generated matchbox digest; this change is the source bump.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
PR #2711 switched PR builds to push only :pr-<N>-<sha> tags (PUBLISH_FLOATING=0) to stop concurrent-push 409 conflicts, but left --cache-from pointing at $(REGISTRY)/<img>:latest. PR builds set REGISTRY to the per-CI registry (iad.ocir.io) and never publish :latest there, so every PR build's registry cache lookup 404s and rebuilds cold.
Add a CACHE_REGISTRY knob (default ghcr.io/cozystack/cozystack, where release builds do publish :latest) and point every --cache-from at it. Push targets ($(REGISTRY)) and the unique per-PR tags are unchanged, so the #2711 anti-conflict behaviour is preserved while PR builds regain a warm cache from the last release.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
The image-talos recipe chains skopeo copy with `;` in a single shell.
Without `set -e`, the recipe's exit status is the last command's, so a
failed copy in the middle of the chain can be masked by a later
successful command — or worse, by a false-branch `if`/`fi` (which exits
0 and would silently hide a push failure on PR builds where both
PUBLISH_* flags are 0).
Prepend `set -e;` to abort the recipe on the first failure. Also quote
"$SRC" defensively.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Every package Makefile tagged images via `settag` which, on a non-release
commit, collapsed to `:latest`. Concurrent PR builds therefore raced on every
image's `:latest` manifest in the OCIR registry. Two outliers (metallb,
redis-operator) used hardcoded version tags and collided across PRs even when
`settag` would not have.
Replace `settag` and the `TAG=latest` fallback with an `image-tags` macro
driven by three env vars:
- IMAGE_TAG — build-unique tag, always pushed
- PUBLISH_VERSIONED — also push :<component-version>
- PUBLISH_FLOATING — also push :latest
PR CI sets IMAGE_TAG=pr-<N>-<sha> with both PUBLISH_* off, so every push is
unique across runs. Release CI sets IMAGE_TAG=<git-tag> with both PUBLISH_*
on, preserving the previous release output and adding a uniform :<git-tag>
tag across every image. Local builds default to IMAGE_TAG=dev with PUSH=0
already off.
Image consumers reference digests pinned into values.yaml by each Makefile,
so the tag is decorative for cluster-side pulls; the build-unique tag is
sufficient for E2E.
Drops the redundant `:<component-version>-<git-tag>` form (cilium, linstor,
matchbox, ubuntu-container-disk, kubevirt-*, cluster-autoscaler) — nothing
in the repo or downstream values.yaml consumed it. The same information is
preserved via the new uniform `:<git-tag>` plus the existing
`:<component-version>` on release.
ubuntu-container-disk builds a separate image per Kubernetes version in a
loop. Switched its primary tag to `:<k8s-ver>-<IMAGE_TAG>` so loop
iterations within a single build do not push to the same tag.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Bumps Talos Linux from v1.12.7 to v1.13.0. The v1.13 release line also
contains the kernel fix for CVE-2026-31431 ("Copy Fail").
Refreshes the bundled system extension digests (amdgpu, i915, drbd, zfs)
to their 1.13.0-aligned builds.
Generated via `make update` in packages/core/talos.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
Bumps Talos Linux from v1.12.6 to v1.12.7, which includes the kernel
fix for CVE-2026-31431 ("Copy Fail") — an unprivileged-to-root local
privilege escalation in the Linux kernel crypto subsystem (algif_aead).
Also refreshes the bundled system extension digests (amd-ucode, amdgpu,
bnx2-bnx2x, i915, intel-ice-firmware, qlogic-firmware, drbd, zfs) to
their 1.12.7-aligned builds.
Generated via `make update` in packages/core/talos.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
Add file existence checks to talos asset targets to prevent
rebuilding kernel, initramfs, installer, iso, nocloud, and metal
assets when they already exist from a previous build step.
This fixes duplicate talos builds in the release pipeline where
`make build` and `make assets` both triggered talos image generation.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
Move common-envs.mk and package.mk from scripts/ to hack/ directory.
Update all Makefile includes to use new paths. Remove unused
issue-flux-certificates.sh script.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
Aleksei Sviridkin