[matthewgrossman]

Summary

The ubuntu-k3s tmachine environment downloads https://get.k3s.io and checks it against a pinned sha256. get.k3s.io always serves the latest install.sh from k3s master, so the pin broke when upstream changed the script. This downloads install.sh from the release tag that matches k3s_version instead and pins that checksum.

Related Issue

None. This is a CI build fix (no issue required for authors with write access, per CONTRIBUTING.md). It unblocks #5137, #5138 and #5196.

Failure: both conformance-integration / E2E suites (conformance/conformance, ubuntu-k3s, k3s) and ... k3s-ha fail in provisioning at the Ansible task "Download K3s installer" in tests/tmachine/ansible/playbooks/k3s.yaml, before any test runs.

• Old pin e5cc3b3d9dfc1662c2d9be6da5abc9a4cd317d6abc3a5ffc02e3dd3248207fee is install.sh at k3s-io/k3s@2977c52.
• get.k3s.io now serves c2a2643dd7c259121a876d16538844c60928de3d38ae98f22f7b95a7ffcfab9d, which is install.sh at k3s-io/k3s@2b723db (Fix bashisms in install.sh k3s-io/k3s#14948, "Fix bashisms in install.sh", merged 2026-11-03 19:51 UTC). That upstream change only swaps type for command -v and {1..3} for 1 2 3.

Changes

• Download the installer from https://raw.githubusercontent.com/k3s-io/k3s/v{{ k3s_version | urlencode }}/install.sh, which renders to .../v1.29.15%2Bk3s1/install.sh (tag commit k3s-io/k3s@35a4723).
• Pin its sha256, 3ce239d57d43b2d836d2b561043433e6decae8b9dc41f5d13908c0fafb0340cd, and add a comment to update the checksum whenever k3s_version changes. A version bump changes the URL, so a stale checksum fails loudly.

Behaviour differences between the v1.29.15+k3s1 script and the previously pinned master script, for how this playbook uses it (INSTALL_K3S_VERSION, server --disable=servicelb --disable=traefik, Ubuntu 24.04 with systemd):

• Argument and INSTALL_K3S_VERSION handling are identical.
• The release script builds GitHub release URLs with a literal + (.../download/v1.29.15+k3s1/k3s) rather than %2B. Both forms return 200 from GitHub today.
• The generated systemd unit has an extra ExecStartPre that fails if nm-cloud-setup.service is enabled (not present on the Ubuntu image) and no explicit User=root (the default for system units).
• The memory-cgroup check only logs a hint; the uninstall/killall scripts and SELinux RPM handling differ but are not used here.

Testing

• ansible-playbook --syntax-check passes for tests/tmachine/ansible/playbooks/k3s.yaml
• Ran the get_url task locally with k3s_version=1.29.15+k3s1: the URL renders with %2B, downloads, and matches the pinned checksum
• ubuntu-k3s conformance rows (k3s, k3s-ha) pass in CI
• Unit tests added/updated (if applicable)
• E2E tests added/updated (if applicable)

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated (if applicable)

[github-actions]

Label test:e2e applied for 68a7aa9. Open the existing run and click Re-run all jobs to execute with the label set. The run will execute the standard E2E suite after building the required gateway, sandbox, and supervisor images once. The matching required CI gate status on this PR will flip green automatically once the run finishes.