chore(deps): update runc-containerd-minor to v2.3.1-ubuntu24.04u2 - autoclosed

[renovate]

This PR contains the following updates:

Package	Update	Change
moby-containerd	minor	2.2.4-ubuntu24.04u2 → 2.3.1-ubuntu24.04u2

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[djsly]

Linux Gate Detective RCA — build 166961552

Status: CIS regression on Ubuntu 24.04 gen2 containerd; now correlated with a second matching failure shape on PR #8294
Failure: build2404gen2containerd failed CIS baseline comparison: rule 6.1.4.1 pass→fail
Run: https://msazure.visualstudio.com/CloudNativeCompute/_build/results?buildId=166961552

RCA: The first failing step is Test, Scan, and Cleanup via vhdbuilder/packer/test/run-test.sh → vhdbuilder/packer/vhd-scanning.sh, where CIS scan output is compared against the checked-in Ubuntu 24.04 baseline. The regression signature was:

CIS regressions detected: 1
Regression details (rule_id|baseline->current): 6.1.4.1|pass->fail

Rule 6.1.4.1 is "Ensure access to all logfiles has been configured". It scans /var/log and fails if any regular logfile has non-compliant mode/owner/group. The original suspect was the Ubuntu 24.04u2 runc/containerd package bump leaving a new or changed logfile footprint, but the same CIS rule has now shown up on PR #8294 as well, so this looks more like Ubuntu 24.04 baseline/product drift than a uniquely PR-local failure.

Confidence: MEDIUM-HIGH

Next action: compare cis-regressions.txt and the offending /var/log file list between this run and PR #8294 before merging; then either update the baseline/remediation if expected, or fix the package/logfile permissions if unexpected.

[djsly]

AgentBaker Linux PR gate — CIS regression

• Run: 166961552 (partiallySucceeded)
• Failed job/task: build2404gen2containerd → Test, Scan, and Cleanup
• Signature: CIS regressions detected: 1 — rule 6.1.4.1 pass→fail (Ubuntu 24.04 L1: Ensure access to all logfiles has been configured). Only 24.04 gen2 SKU regressed; 12 other SKUs and E2E green.

Likely cause (high confidence, change-caused): the runc/containerd bump in parts/common/components.json (v2.3.1-ubuntu24.04u2) deposits a file under /var/log with mode/owner/group outside the CIS allow-list (commonly mode > 0640 or group ∉ {adm,syslog,utmp,systemd-journal}). PR is the only delta; vhdbuilder/packer/cis/baselines/ubuntu/24.04.txt is unchanged.

Strongest alternative (less likely): baseline staleness for 24.04 — ruled lower because only the targeted SKU regressed in a 13-SKU matrix and the baseline file is unchanged. (Note: a second renovate PR has since hit the same rule — see #8294 — so the baseline-drift hypothesis is now stronger; please coordinate.)

Recommended next action: download cis-regressions.txt from the failed job — it names the exact /var/log path and observed vs expected perms. Then either chmod/chown in the install step (vhdbuilder/packer/install-dependencies.sh), update the 24.04 baseline if intentional, or push back upstream. Owner: PR author / NodeSIG-dev renovate-gate triage.

Posted by Clawpilot AgentBaker gate detective.

[aks-node-assistant]

AgentBaker Linux PR gate — Ubuntu 24.04 fwupd.service mass E2E failure (RECURRING main regression, NOT this PR)

• Run: 167310976 (failed) — new commit c240ea2 (runc/containerd → v2.3.1-ubuntu24.04u2)
• Failed task: Run AgentBaker E2E
• Test summary: DONE 438 tests, 95 skipped, 13 failures in 1720.374s
• Primary signature: validators.go:995: 🔴 FAIL: the following systemd units have unexpectedly entered a failed state: [fwupd.service] (7 hits)

Failing scenarios — all Ubuntu 24.04 (random-VHD picker selected a 24.04 image): Test_Random_VHD_With_Latest_Kubernetes_Version, Test_Ubuntu2404_CSE_CachedPerformance, Test_Ubuntu2404_CSE_FullInstallPerformance, Test_Ubuntu2404_SecureTLSBootstrapping_BootstrapToken_Fallback, Test_Ubuntu2404Gen2_McrChinaCloud, Test_Ubuntu2404Gen2_McrChinaCloud_Scriptless.

Same fwupd.service 24.04 main regression previously flagged on builds 167206065, 167219726, 167221197, 167238023, 167241354, 167255168, 167255195. New runc/containerd commit (u1 → u2) does not change the failure shape or scope.

Build-vs-test: product/VHD regression caught by E2E (NOT a flake, NOT test-code, NOT runc/containerd-related).
This PR's exposure check: the failing validator is the systemd-unit health check tripping on fwupd.service. No new containerd/runc-specific failure mode introduced by the u2 bump.
Confidence: HIGH that PR #8652 is not the cause; HIGH that this is the same recurring 24.04 VHD main regression around fwupd.service.
Strongest alternative (less likely): runc/containerd v2.3.1-u2 specifically breaking fwupd.service on 24.04 — refuted: identical signature reproduces on PRs that don't touch runc/containerd (#8294, #8600, #8618, #8642) on the same main HEAD, and the prior u1 bump on this same PR hit the identical signature.

Recommended next action / owner: NodeSIG-dev — main fix still pending (>12h since first sighting). Likely mitigation: mask fwupd.service in 24.04 VHD or fix the first-start dependency in vhdbuilder/packer/install-dependencies.sh / tool_installs_distro.sh. PR author: do NOT block merge on this; rebase + rerun once the main fix lands.

Posted by Clawpilot AgentBaker gate detective.

[aks-node-assistant]

Fwupd 24.04 gate regression — fix incoming, no action needed on this PR

The Ubuntu 24.04 [fwupd.service] mass-failure flagged on your prior gate run is now tracked and being fixed:

• Fix PR: #8662 — fix(vhd): mask fwupd on Ubuntu 24.04 to unblock E2E PR gate
• Tracker: AB#38355676 (Sev1)

Once #8662 merges, rerun the gate on this PR. No code change required on your side.

Posted by Clawpilot AgentBaker gate detective.

[aks-node-assistant]

AgentBaker Linux PR gate — 236-failure mass run: shared cluster proxy-pod readiness + ResourceGroupBeingDeleted (test-infra, NOT this PR)

• Run: 167387444 (failed)
• Failed task: Run AgentBaker E2E
• Test summary: DONE 402 tests, 95 skipped, 236 failures in 698.070s (~59% failure rate; 0 fwupd hits)

Two-bucket failure shape — both test-infra:

• Bucket A (dominant, ~133+ scenarios): prepare cluster tasks: dag execution failed: waiting for proxy pod to be ready: listing proxy pods: client rate limiter Wait returned an error: context deadline exceeded. The harness's e2e-proxy DaemonSet pods never reach ready before the test framework's kube-client hits its client-side rate-limit timeout.
• Bucket B (~20 scenarios): RESPONSE 409: ResourceGroupBeingDeleted on the shared MC RG for abe2e-kubenet-v5-* — same pattern as build 167378787 earlier this evening.

Three-level analysis:

1. L1: proxy DaemonSet pods don't go ready in time; kube client's RetryAfter/rate-limiter eats the remaining context.
2. L2 corroboration: identical signature across 3 concurrent PRs in the same window — 167387444 (this PR, runc/containerd), 167387406 (PR chore(deps): update node-exporter-kubernetes (patch) #8294 node-exporter), 167387387 (PR chore(deps): update kubelet-kubectl (patch) #8600 kubelet/kubectl) — all 236 failures, all ~60% rate, same proxy-pod-readiness + RG-being-deleted mix. Three unrelated PRs, identical failure shape, on the same shared test cluster ecosystem.
3. L3 challenge: alternatives — (a) PR-caused (runc/containerd v2.3.1-u2 bump breaking proxy pod): refuted, two unrelated PRs hit the identical signature in the same window; (b) AKS API throttling: partial root cause but the underlying trigger is the shared cluster pool being overloaded/torn down — Bucket A and Bucket B point to the same shared-cluster-fleet stress.

Build-vs-test: test-infra (shared cluster pool: proxy DaemonSet readiness + RG lifecycle), NOT product, NOT PR-caused.
Confidence: HIGH that PR #8652 is not the cause.

Recommended next action / owner: E2E infra / NodeSIG-dev — the shared cluster fleet (abe2e-kubenet-v5-*, abe2e-azure-networkisolated-v2-b64ad) is overloaded or being torn down while runs are using it; the proxy DaemonSet's ready-wait + kube-client rate-limiter combination is hitting its budget. Same recurring kubenet-v5/cluster-pool instability flagged on builds 167378787, 167348100, 167244552, 167350983. PR author: do NOT block merge on this; rerun once shared cluster fleet stabilizes.

Posted by Clawpilot AgentBaker gate detective.

[github-actions]

Changes cached containers or packages on windows VHDs

Please get a Windows SIG member to approve.

The following dif file shows any additions or deletions from what will be cached on windows VHDs organised by VHD type.

• Additions are new things cached.
• Deletions are things no longer cached.

diff --git a/vhd_files/2022-containerd-gen2.txt b/vhd_files/2022-containerd-gen2.txt
index c51a47f..5bece34 100644
--- a/vhd_files/2022-containerd-gen2.txt
+++ b/vhd_files/2022-containerd-gen2.txt
@@ -138,0 +139 @@ mcr.microsoft.com/windows/nanoserver:ltsc2022
+mcr.microsoft.com/windows/servercore:10.0.20348.5020
@@ -140 +140,0 @@ mcr.microsoft.com/windows/servercore:10.0.20348.5139
-mcr.microsoft.com/windows/servercore:10.0.20348.5256
@@ -146 +146 @@ Windows 2022-containerd-gen2 base image sku: 2022-datacenter-core-smalldisk-g2
-Windows 2022-containerd-gen2 base version: 20348.5256.260607
+Windows 2022-containerd-gen2 base version: 20348.5139.260507
diff --git a/vhd_files/2022-containerd.txt b/vhd_files/2022-containerd.txt
index 7312c49..f91de3f 100644
--- a/vhd_files/2022-containerd.txt
+++ b/vhd_files/2022-containerd.txt
@@ -138,0 +139 @@ mcr.microsoft.com/windows/nanoserver:ltsc2022
+mcr.microsoft.com/windows/servercore:10.0.20348.5020
@@ -140 +140,0 @@ mcr.microsoft.com/windows/servercore:10.0.20348.5139
-mcr.microsoft.com/windows/servercore:10.0.20348.5256
@@ -146 +146 @@ Windows 2022-containerd base image sku: 2022-Datacenter-Core-smalldisk
-Windows 2022-containerd base version: 20348.5256.260607
+Windows 2022-containerd base version: 20348.5139.260507
diff --git a/vhd_files/2025-gen2.txt b/vhd_files/2025-gen2.txt
index 36e3641..a08e5a4 100644
--- a/vhd_files/2025-gen2.txt
+++ b/vhd_files/2025-gen2.txt
@@ -69,0 +70 @@ mcr.microsoft.com/windows/nanoserver:ltsc2025
+mcr.microsoft.com/windows/servercore:10.0.20348.5020
@@ -71 +72 @@ mcr.microsoft.com/windows/servercore:10.0.20348.5139
-mcr.microsoft.com/windows/servercore:10.0.20348.5256
+mcr.microsoft.com/windows/servercore:10.0.26100.32690
@@ -73 +73,0 @@ mcr.microsoft.com/windows/servercore:10.0.26100.32860
-mcr.microsoft.com/windows/servercore:10.0.26100.32995
@@ -80 +80 @@ Windows 2025-gen2 base image sku: 2025-datacenter-core-smalldisk-g2
-Windows 2025-gen2 base version: 26100.32995.260607
+Windows 2025-gen2 base version: 26100.32860.260510
diff --git a/vhd_files/2025.txt b/vhd_files/2025.txt
index b8873d5..50a0258 100644
--- a/vhd_files/2025.txt
+++ b/vhd_files/2025.txt
@@ -69,0 +70 @@ mcr.microsoft.com/windows/nanoserver:ltsc2025
+mcr.microsoft.com/windows/servercore:10.0.20348.5020
@@ -71 +72 @@ mcr.microsoft.com/windows/servercore:10.0.20348.5139
-mcr.microsoft.com/windows/servercore:10.0.20348.5256
+mcr.microsoft.com/windows/servercore:10.0.26100.32690
@@ -73 +73,0 @@ mcr.microsoft.com/windows/servercore:10.0.26100.32860
-mcr.microsoft.com/windows/servercore:10.0.26100.32995
@@ -80 +80 @@ Windows 2025 base image sku: 2025-datacenter-core-smalldisk
-Windows 2025 base version: 26100.32995.260607
+Windows 2025 base version: 26100.32860.260510