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

[renovate]

This PR contains the following updates:

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

---

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 — 236-failure run: shared cluster fleet outage continues — failed to wait for cluster ... context deadline exceeded + ResourceGroupDeletionBlocked (test-infra, NOT this PR)

• Run: 167419663 (failed)
• Failed task: Run AgentBaker E2E (60-minute timeout consumed)
• Test summary: DONE 402 tests, 95 skipped, 236 failures in 3617.453s (~59% failure rate; 0 fwupd hits)

Dominant failure signatures (cluster fleet still broken since last night):

• 113× get or create cluster: failed to get existing cluster "abe2e-kubenet-v5-150ee": failed to wait for cluster to be ready: context deadline exceeded, and wont retry
• 10× same against abe2e-latest-kubernetes-version-v2-d6af0
• 42× ResourceGroupDeletionBlocked on shared MC RGs (abe2e-azure-networkisolated-v2-b64ad, abe2e-azure-v4-ce2ad, abe2e-azure-bootstrapprofile-cache-v2-26798)

The shared clusters either can't be retrieved at all (timing out the prepare-cluster phase) or are stuck in a deletion-blocked state. This is the continued degradation of the same shared cluster fleet flagged on overnight runs 167387444, 167387406, 167387387, 167393232, 167398747, 167378787 — now with each run consuming the full 60-min timeout instead of 11 min, indicating the fleet has gotten worse, not better.

Cross-PR pattern in same window: identical 236-failure / cluster-not-ready signature on PR #8679 build 167421198, PR #8294 build 167422687, and concurrent PRs.

Build-vs-test: test-infra (shared cluster fleet outage), NOT product, NOT PR-caused.
Confidence: HIGH that PR #8652 is not the cause.

Recommended next action / owner: ⚠️ E2E infra / NodeSIG-dev — this needs urgent intervention: rebuild or re-provision the abe2e-kubenet-v5-*, abe2e-latest-kubernetes-version-v2-*, abe2e-azure-networkisolated-v2-*, abe2e-azure-v4-*, and abe2e-azure-bootstrapprofile-cache-v2-* shared clusters; clear the ResourceGroupDeletionBlocked locks on the MC RGs. Until this is done, every PR's E2E run will consume the full 60-min timeout and post a meaningless 236-failure result, blocking the entire gate. PR author: do NOT block merge intent on this; rerun once fleet is restored.

Posted by Clawpilot AgentBaker gate detective.