chore(deps): bump the talos group across 1 directory with 3 updates

[dependabot]

Bumps the talos group with 3 updates in the / directory: github.com/siderolabs/talos, github.com/siderolabs/talos/pkg/machinery and github.com/siderolabs/omni/client.

Updates github.com/siderolabs/talos from 1.14.0-alpha.2 to 1.15.0-alpha.0

Release notes

Sourced from github.com/siderolabs/talos's releases.

v1.15.0-alpha.0

Talos 1.15.0-alpha.0 (2026-09-08)

Welcome to the v1.15.0-alpha.0 release of Talos!
This is a pre-release of Talos

Please try out the release binaries and report any issues at https://github.com/siderolabs/talos/issues.

containerd Configuration Version 4

Talos now generates containerd configuration with version = 4 (previously version = 3).

containerd only migrates configuration from older versions, so any custom CRI configuration provided via CRICustomizationConfig documents (or shipped by system extensions) is now interpreted as version 4, and settings which moved in version 4 are silently ignored (only a Ignoring unknown key in TOML warning is logged by containerd).

In version 4, the top-level server sections moved into plugin configuration blocks, so the following patches need to be adjusted:

version 3	version 4
[metrics] address	[plugins."io.containerd.server.v1.metrics"] address
[metrics] grpc_histogram	[plugins."io.containerd.metrics.v1.grpc-prometheus"] grpc_histogram
[grpc] address, uid, gid, max_recv_message_size, max_send_message_size	[plugins."io.containerd.server.v1.grpc"] (same keys)
[grpc] tcp_address, tcp_tls_ca, tcp_tls_cert, tcp_tls_key, tcp_tls_common_name	[plugins."io.containerd.server.v1.grpc-tcp"] address, tls_ca, tls_cert, tls_key, tls_common_name
[ttrpc] address, uid, gid	[plugins."io.containerd.server.v1.ttrpc"] (same keys)
[debug] address, uid, gid	[plugins."io.containerd.server.v1.debug"] (same keys)

For example, the containerd metrics customization documented for previous versions of Talos:

apiVersion: v1alpha1
kind: CRICustomizationConfig
name: enable-metrics
content: |
  [metrics]
    address = "0.0.0.0:11234"

should now be written as:

apiVersion: v1alpha1
kind: CRICustomizationConfig
name: enable-metrics
content: |
  [plugins."io.containerd.server.v1.metrics"]
    address = "0.0.0.0:11234"
</tr></table> 

... (truncated)

Commits

• 12dfb8e release(v1.15.0-alpha.0): prepare release
• f3017d3 fix: add missing extension test patches for nfs
• 67ae852 fix: wait for USB settle explicitly
• 274dc85 fix(security): define the permissions the 6.18 kernel expects in the classes
• 28841f4 fix: empty searchdomains dropped on merge
• 5a67d1e chore: support correctly various disk types for the system disk
• 834ba88 fix: improve resilience of the action tracker against dropped conns
• a2d35a9 fix: notify about link alias changes
• 9de219c test: nvidia - switch to nri
• 24ef6f4 fix: use the final config version in upgrade-k8s
• Additional commits viewable in compare view

Updates github.com/siderolabs/talos/pkg/machinery from 1.14.0-alpha.2 to 1.15.0-alpha.0

Release notes

Sourced from github.com/siderolabs/talos/pkg/machinery's releases.

v1.15.0-alpha.0

Talos 1.15.0-alpha.0 (2026-09-08)

Welcome to the v1.15.0-alpha.0 release of Talos!
This is a pre-release of Talos

Please try out the release binaries and report any issues at https://github.com/siderolabs/talos/issues.

containerd Configuration Version 4

Talos now generates containerd configuration with version = 4 (previously version = 3).

containerd only migrates configuration from older versions, so any custom CRI configuration provided via CRICustomizationConfig documents (or shipped by system extensions) is now interpreted as version 4, and settings which moved in version 4 are silently ignored (only a Ignoring unknown key in TOML warning is logged by containerd).

In version 4, the top-level server sections moved into plugin configuration blocks, so the following patches need to be adjusted:

version 3	version 4
[metrics] address	[plugins."io.containerd.server.v1.metrics"] address
[metrics] grpc_histogram	[plugins."io.containerd.metrics.v1.grpc-prometheus"] grpc_histogram
[grpc] address, uid, gid, max_recv_message_size, max_send_message_size	[plugins."io.containerd.server.v1.grpc"] (same keys)
[grpc] tcp_address, tcp_tls_ca, tcp_tls_cert, tcp_tls_key, tcp_tls_common_name	[plugins."io.containerd.server.v1.grpc-tcp"] address, tls_ca, tls_cert, tls_key, tls_common_name
[ttrpc] address, uid, gid	[plugins."io.containerd.server.v1.ttrpc"] (same keys)
[debug] address, uid, gid	[plugins."io.containerd.server.v1.debug"] (same keys)

For example, the containerd metrics customization documented for previous versions of Talos:

apiVersion: v1alpha1
kind: CRICustomizationConfig
name: enable-metrics
content: |
  [metrics]
    address = "0.0.0.0:11234"

should now be written as:

apiVersion: v1alpha1
kind: CRICustomizationConfig
name: enable-metrics
content: |
  [plugins."io.containerd.server.v1.metrics"]
    address = "0.0.0.0:11234"
</tr></table> 

... (truncated)

Commits

• 12dfb8e release(v1.15.0-alpha.0): prepare release
• f3017d3 fix: add missing extension test patches for nfs
• 67ae852 fix: wait for USB settle explicitly
• 274dc85 fix(security): define the permissions the 6.18 kernel expects in the classes
• 28841f4 fix: empty searchdomains dropped on merge
• 5a67d1e chore: support correctly various disk types for the system disk
• 834ba88 fix: improve resilience of the action tracker against dropped conns
• a2d35a9 fix: notify about link alias changes
• 9de219c test: nvidia - switch to nri
• 24ef6f4 fix: use the final config version in upgrade-k8s
• Additional commits viewable in compare view

Updates github.com/siderolabs/omni/client from 1.9.1 to 1.12.2

Release notes

Sourced from github.com/siderolabs/omni/client's releases.

v1.12.2

Omni 1.12.2 (2026-09-23)

Welcome to the v1.12.2 release of Omni!

Please try out the release binaries and report any issues at https://github.com/siderolabs/omni/issues.

Contributors

• Utku Ozdemir
• immanuwell
• Edward Sammut Alessi

Changes

• 020bfffc1 release(v1.12.2): prepare release
• 26fdb97e5 fix: keep the cached Talos clients alive while they are in use
• c7f88c92a fix: reject unknown omnictl config contexts
• 318674380 fix: do not report k8s manifests as deleting when Omni does not own them
• 607d07bb4 fix(frontend): show enterprise label for cluster on overview
• 259aa95ce fix: forbid changing roles to or from InfraProvider
• 5678d3a89 fix: honor context override in omnictl config info

Dependency Changes

This release has no dependency changes

Previous release can be found at v1.12.1

v1.12.1

Omni 1.12.1 (2026-09-15)

Welcome to the v1.12.1 release of Omni!

Please try out the release binaries and report any issues at https://github.com/siderolabs/omni/issues.

Contributors

• Edward Sammut Alessi
• Andrey Smirnov

... (truncated)

Commits

• 020bfff release(v1.12.2): prepare release
• 26fdb97 fix: keep the cached Talos clients alive while they are in use
• c7f88c9 fix: reject unknown omnictl config contexts
• 3186743 fix: do not report k8s manifests as deleting when Omni does not own them
• 607d07b fix(frontend): show enterprise label for cluster on overview
• 259aa95 fix: forbid changing roles to or from InfraProvider
• 5678d3a fix: honor context override in omnictl config info
• 97e51ea release(v1.12.1): prepare release
• 60deeec test: drop MinIO usage in the tests
• 663e550 feat(frontend): show a message that cluster security UI requires enterprise
• Additional commits viewable in compare view

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[github-actions]

✅MegaLinter analysis: Success

✅ Linters with no issues

actionlint, bash-exec, git_diff, hadolint, jscpd, jsonlint, lychee, markdown-table-formatter, markdownlint, prettier, prettier, shellcheck, shfmt, stylelint, syft, trivy-sbom, trufflehog, v8r, v8r, yamllint

Notices

⚠️ Your configuration references items that have been removed from MegaLinter and are ignored: REPOSITORY_GITLEAKS. See Removed linters to find their replacements.

See detailed reports in MegaLinter artifacts

Show us your support by starring ⭐ the repository

[devantler]

🤖 Generated by the Agentic Engineer

Parked on a named, live-verified blocker — not actionable here, and closing it does not help.

This PR bumps the Talos group v1.14.0-alpha.2 → v1.14.0-rc.2. All 24 failing checks come from a
single go build -v ./... step, and they are the upstream wall already tracked on #6728 / #6776:

pkg/fsutil/configmanager/talos/configs.go:615:54  cp.Machine().Kubelet undefined
pkg/fsutil/configmanager/talos/configs.go:619:28  cp.Machine().Kubelet undefined
pkg/fsutil/configmanager/talos/version.go:244:28  machineCfg.Kubelet undefined
loft-sh/apiserver@v0.0.0-20260707184419.../pkg/builders/default_storage_strategy.go:33:33
    *DefaultStorageStrategy does not implement rest.RESTUpdateStrategy
k8s.io/cri-client@v0.36.1/pkg/remote_runtime.go:150:9
    *remoteRuntimeService does not implement apis.RuntimeService (missing CheckpointPod)

This is NOT the grouped-update/desktop-module cause (#6816). On this head
🧩 Verify Desktop Module Tidy and 📦 Tidy both report SUCCESS — the PR gets past tidiness and
fails in the build itself. Worth stating explicitly because #6819's cause table attributes this PR's
predecessor (#6813) to #6816, so fixing #6816 would not unblock this one.

Closing it is ineffective — measured today. #6813 was closed as a stalled talos-group PR at
17:14:53Z; dependabot opened this PR at 17:20:49Z, 6 minutes later. A close is not a terminal
state for this class while the group is still configured; only #6776 landing (or the group being
paused) stops the churn.

Blocker: loft-sh/apiserver — needs a revision built against Kubernetes 0.37 apiserver | last-verified 2026-09-01: not shipped. Newest published revision is still v0.0.0-20260707184419-aef558a5ae8d, pinning the 0.36 apiserver.

Leaving this open and parked rather than closing it. It should go green on its own once #6776 lands.

[devantler]

🤖 Generated by the Agentic Engineer

This PR has been DIRTY (conflicting with main) since 18:13Z with auto-merge armed at 17:21Z and
no bot update in flight, so it cannot reach merge on its own. Requesting the bot's own rebase — the
least-invasive action that can finish this exact head — rather than pushing an adaptation commit.

@dependabot rebase

[dependabot]

Looks like this PR has been edited by someone other than Dependabot. That means Dependabot can't rebase it - sorry!

If you're happy for Dependabot to recreate it from scratch, overwriting any edits, you can request @dependabot recreate.

[devantler]

🤖 Generated by the Agentic Engineer

Same root cause as #6830: Dependabot cannot rebase because ksail-bot pushed chore: sync modules and update generated files (17:31:36Z) onto this branch, so the PR forfeits self-healing the moment main moves.

This head is both DIRTY and failing 38 checks against a stale base, so the two causes are currently indistinguishable. Rebuilding in place on the same PR (not closing it — closing recreates a new PR, which is how #6813 became this one) separates them: if the failures persist on a fresh base, the talos bump is genuinely incompatible and gets its own fix.

@dependabot recreate

[devantler]

🤖 Generated by the Agentic Engineer

Named cause, replacing "38 failing checks against a stale base". The rebuild cleared the conflict (DIRTY → BLOCKED, head 200115a8 → b4ef2a48), and the remaining failures are not a talos incompatibility. The build fails on:

go: updates to go.mod needed; to update it:
	go mod tidy

recreate discarded ksail-bot's chore: sync modules and update generated files commit and ksail-bot has not re-applied it, so go.mod is untidied. Failing: 🏗️ Build (Linux), 🏗️ Build + cask (macOS), 🔍 Dead Code Analysis, 🛡️ Vulnerability Scan.

⚠️ Do not unstick this by pushing go mod tidy by hand — that push is again "someone other than Dependabot" and forfeits rebase all over again, which is the original defect. Tracked with the full analysis in #6832.

[devantler]

🤖 Generated by the Agentic Engineer

Correction to my comment above. I wrote that ksail-bot "has not re-applied" its sync. That was read off a 6-minute window while CI was still mid-flight, and ci.yaml runs the sync job on pull_request (no type filter, so synchronize is included) — so it should re-fire on the rebuilt head and had simply not reached that stage.

The go mod tidy build failure is consistent with the build running before the sync lands, i.e. an expected transient rather than a terminal state. The named cause stands as "sync not yet applied at build time", not "sync will never be applied".

Everything else is unchanged: the conflict is cleared, this PR should not be closed, and a manual go mod tidy push would still be the wrong unstick. Full analysis in #6832.

[devantler]

🤖 Generated by the Agentic Engineer

Diagnosed. This PR's red CI is not the Dependabot rebase forfeiture — it is a breaking API change in the bump itself, and it needs a code adaptation before it can go green.

CI is complete at 7673160e93: 39 failing, 18 success, 17 skipped. All 39 are downstream of one compile failure:

pkg/fsutil/configmanager/talos/configs.go:615:54: cp.Machine().Kubelet undefined
  (type config.MachineConfig has no field or method Kubelet)
pkg/fsutil/configmanager/talos/configs.go:619:28: cp.Machine().Kubelet undefined
pkg/fsutil/configmanager/talos/version.go:244:28: machineCfg.Kubelet undefined

machinery dropped the MachineConfig.Kubelet() accessor between v1.14.0-alpha.2 and v1.14.0-rc.2. The three call sites all reach it for the same purpose — reading Kubelet().ExtraArgs() to decide IsKubeletCertRotationEnabled, plus the version probe in version.go:244. A stale doc reference in configs.go:37 names the same accessor.

Not a pre-release-exclusion problem. The obvious-looking remedy is to stop bumping into pre-releases, and that would be wrong here: main is already on v1.14.0-alpha.2, so this repository deliberately tracks the Talos 1.14 pre-release line. alpha.2 → rc.2 is ordinary progression within it, and pinning back would forfeit that intent.

Two things follow.

1. This PR is not repairable by @dependabot recreate. A recreate fixes base drift; it cannot fix a compile break, so the branch would rebuild and stay red. (Do not close it either — closing opens a new number, which is how chore(deps): bump the talos group across 1 directory with 3 updates #6813 became this PR.)
2. Its red CI should not be read as evidence for the severity of ksail-bot's sync commit permanently disables Dependabot rebase, stranding ~half of dependency PRs #6832. I have corrected that framing there — chore(deps): bump github.com/aws/aws-sdk-go-v2/credentials from 1.19.36 to 1.19.38 #6830, which carried only the forfeiture, recreated cleanly and now has 0 failing checks.

The remaining work is a genuine adaptation to the new machinery config API for those three sites. Left in place, red and unmerged, rather than guessed at: the replacement accessor needs to be confirmed against machinery v1.14.0-rc.2 and compile-verified, not inferred from the error text.

[devantler]

🤖 Generated by the Agentic Engineer

Correction to my comment above, and this PR's terminal state: parked on #6728.

I wrote that this PR "needs a code adaptation before it can go green". That is necessary but not sufficient, and acting on it alone would have burned a run for nothing. Adapting the three Kubelet() call sites leaves this PR red.

Evidence — local build at the merged head. I merged origin/main into this branch (resolving the four go.mod/go.sum conflicts as a union: talos stays v1.14.0-rc.2, aws-sdk-go-v2/credentials takes v1.19.38 from #6830), ran go mod tidy, then go build ./.... It fails in three clusters, only the first of which is our code:

1. Ours (3 sites) — cp.Machine().Kubelet / machineCfg.Kubelet undefined at pkg/fsutil/configmanager/talos/configs.go:615,619 and version.go:244. Kubelet() moved off MachineConfig onto the top-level Config as K8sKubeletConfig(); ExtraArgs() map[string][]string is unchanged, so the migration is mechanical.
2. k8s.io/cri-client@v0.36.1 — does not implement cri-api@v0.37.0-rc.1's RuntimeService (missing CheckpointPod). A version skew; cri-client v0.37.0-rc.1 exists, so this half is fixable.
3. github.com/loft-sh/apiserver — AllowCreateOnUpdate() bool vs k8s.io/apiserver@v0.37.0-rc.1's AllowCreateOnUpdate(context.Context) bool. This half is not fixable by us.

Why cluster 3 is the real blocker. github.com/siderolabs/talos@v1.14.0-rc.2's own go.mod requires k8s.io/apimachinery, k8s.io/apiserver and k8s.io/client-go at v0.37.0-rc.1, so the k8s 0.37 bump is forced by the Talos module under MVS — it is not a grouping artifact (pkg/machinery@v1.14.0-rc.2 declares no k8s.io/* dependency at all). Verified against the module proxy today:

• loft-sh/apiserver@latest → v0.0.0-20260707184419-aef558a5ae8d — exactly the pseudo-version already pinned, nothing published since 2026-07-07.
• loft-sh/vcluster@latest → v0.36.1 — already the version we are on.

So there is no version to bump to on either side of the vcluster path. This is the standing ceiling #6728 documents, which already states it directly: "Adapting our own code is not the missing piece … the blocker is strictly the loft-sh one."

Control: main (5c75ced2) is green — 0 failing checks — so this is introduced by the bump, not pre-existing.

Blocker: loft-sh/apiserver k8s-0.37-compatible release | last-verified 2026-09-01: not shipped (@latest still returns the pinned v0.0.0-20260707184419-aef558a5ae8d; loft-sh/vcluster@latest is v0.36.1, already in use)

Disposition. Parked, not closed — closing recreates it under a new number (#6813 → #6826) and cannot fix a compile break. Left un-rebased deliberately: pushing the merge would spend a full 77-check CI cycle on a PR that provably cannot pass. The three call-site migrations land with whichever Talos bump clears #6728, per that issue's acceptance criteria.

[devantler]

🤖 Generated by the Agentic Engineer

Blocker: #6728 | last-verified 2026-09-02: still OPEN — not shipped

Re-verified live this run rather than inherited from the previous park record. This PR stays
parked on a named blocker, which is a terminal state — not an unowned stalled bot PR.

Recording why it is not automation-owned, so a later run does not re-derive it: the branch is
DIRTY, CI - Required Checks is FAILURE with ~38 red checks, and Dependabot has forfeited
rebase on it (edited by someone other than Dependabot). Auto-merge was armed by ksail-bot at
17:21:30Z and structurally cannot fire in that state. So repository automation cannot carry this
head — but the reason it should not simply be repaired by hand is #6728: the bump is unsatisfiable
while Talos beta.1 needs k8s 0.37 and the vcluster stack pins 0.36. Rebasing or forcing it green
would paper over a real version conflict.

Next action belongs to #6728, not here.

[devantler]

🤖 Generated by the Agentic Engineer

Parked on a named upstream blocker, not abandoned. This PR's build failure is not its own: it raises k8s.io/apiserver to v0.37.0 in the selected build list, and both kyverno/kyverno@v1.19.1 and loft-sh/apiserver (via loft-sh/vcluster v0.36.1) fail to compile against the 0.37 packages. I reproduced the failure locally with go build ./..., and confirmed that pinning k8s.io/apiserver back to v0.36.4 does not help — apiserver 0.36 then fails against apimachinery 0.37, so the k8s modules have to move as a set.

kyverno's latest release (v1.19.1, 2026-09-10) still requires k8s 0.36.3, so there is nothing to adapt to on our side yet.

Tracked in #7143 with the evidence and the re-check condition. Leaving this PR open so it rebuilds once kyverno ships a k8s-0.37 release; no adaptation commit, because any adaptation now would be a downgrade of the bump this PR exists to make.

[devantler]

🤖 Generated by the Agentic Engineer

Parked on #7143. This head resolves k8s.io/api and k8s.io/apiserver to v0.37.0. The newest kyverno (v1.19.1) and vcluster (v0.37.1) releases on the Go module proxy still build against k8s 0.36, so the Build/Test/Lint failures here have the same cause as #7127 and #6845. Nothing on this branch can fix that.

Checked 2026-09-21 ~10:50Z: at #7127's head, bumping loft-sh/apiserver to its newest pseudo-version (2026-09-03) still fails with the AllowCreateOnUpdate(context.Context) mismatch, and kyverno v1.19.1 still fails with the admission.LazyObject mismatch. The conflict with main will be resolved when #7143 unblocks. Rebasing before then would not help.

[devantler]

🤖 Generated by the Agentic Engineer

Parked on a named upstream blocker: this bump raises the Kubernetes libraries to v0.37, which vcluster does not support yet (its newest release still builds against v0.36), so the build cannot compile. Tracked in #7167; it will be revisited when vcluster ships support.

[devantler]

🤖 Generated by the Agentic Engineer

Parked on #7259. This bump pulls k8s.io/client-go to v0.37.0, and ksail cannot compile against the v0.37 Kubernetes libraries until Kyverno and vcluster ship compatible releases (neither has as of 2026-09-24). The red build and the conflict both clear once main moves to v0.37; that work is tracked on #7259.

[devantler]

🤖 Generated by the Agentic Engineer

Blocker: #7259 | upstream | last-verified 2026-10-19: 2026-10-19 Go module proxy: Kyverno v1.19.1 and every v1.19.2 release candidate (rc.1, rc.2, rc3) still require Kubernetes v0.36.x (rc.2: v0.36.4); vcluster v0.38.0-alpha.4 (newest) still requires v0.36.3. Issue #7259 is open. Earlier record (2026-10-17): At head 1943944: 2026-10-17 Go module proxy: stable Kyverno v1.19.1 and its v1.19.2-rc.1 still require Kubernetes v0.36.3; stable vcluster v0.37.3, v0.37.4-rc.1 and v0.38.0-alpha.4 still require v0.36.0 or v0.36.3. Issue #7259 is open. Not rebuilt at this head; no unchanged retry or check waiver. The branch also conflicts with main and needs the Talos accessor migration tracked in #6776 (open).

[devantler]

🤖 Generated by the Agentic Engineer

@dependabot recreate