[sjmiller609]

Summary

Upgrade the default guest kernel from ch-6.12.8-kernel-3.0-202605291 to ch-6.12.8-kernel-3.2-202610301 (Linux 6.12.8). Register its x86_64/aarch64 kernel and header URLs, put it first in the supported list, and retain older versions.

Kernel 3.2 adds built-in IPv6 plus IPv4 TPROXY and policy routing. Release CI passed and both packaged configurations were verified: https://github.com/kernel/linux/releases/tag/ch-6.12.8-kernel-3.2-202610301

Deployment behavior

• New instances without an explicit kernel label select 3.2. This PR intentionally changes the default, rather than merely registering an opt-in kernel. It does not rewrite existing instance metadata or enable browser/provider IPv6 proxying.
• API startup eagerly ensures every supported kernel for the host architecture, downloading uncached artifacts. Registering 3.2 adds a startup download dependency; a download failure prevents API startup.
• The shared initrd uses DefaultKernelVersion for both its header URL and content hash. Changing the default rebuilds the initrd with 3.2 headers, aligning newly created default guests with their kernel. The rebuild also requires fetching the header archive and Alpine base.
• Per-instance header selection remains unsupported: guests pinned to older kernels still receive the shared default initrd on boot. This change does not establish DKMS compatibility for mixed kernel versions or replace already-installed guest headers by artifact identity. Validate GPU/DKMS and persistent guest state before rollout.
• No hosts have been upgraded by this PR update.

Validation

• Passed make build-embedded, go test -short -race ./lib/system/..., and go vet ./lib/system/... locally. The embedded builds compile the Go guest-agent/init programs, not the Linux kernel.
• Passed focused version tests/race and vet. Tests cover the new default, supported-list order, retention of 3.0, and both architecture download/header mappings.
• Prior kernel 3.2 runtime smoke tests passed in an isolated x86_64 Firecracker guest: boot/restart, native IPv6 TCP/UDP loopback and sysctls, IPv4 UDP interception/replies and direct-leak prevention, Chromium HTTP/CDP/DNS and synthetic STUN, plus standby/restore and repeated checks.
• Those runtime tests used a private kernel-cache override with an unchanged controller and skipped kernel-header installation. They do not validate this PR's default-selection/initrd rebuild path or GPU/DKMS. Loaded kernel SHA-256: 81968e74a25be2ecb5e3dcc47f63cffe52609f3ef77d24883fef9e5d09f50709.
• Full local integration tests, ARM64/Cloud Hypervisor runtime tests, real provider exit-IP matching, live view and fork lifecycle remain unverified. The experimental UDP image also retains an independent cold-restart namespace cleanup bug.

---

Note

Medium Risk
Changing the default guest kernel affects new instance boot, initrd/header alignment, and startup artifact downloads, though existing pinned instances are unchanged by this diff alone.

Overview
Bumps the default guest kernel from ch-6.12.8-kernel-3.0-202605291 to ch-6.12.8-kernel-3.2-202610301, documented as adding IPv4 TPROXY, policy routing, and IPv6.

The new artifact is registered at the top of SupportedKernelVersions, with x86_64/aarch64 entries in KernelDownloadURLs and KernelHeaderURLs. Older kernels stay supported. Tests assert parsing, default selection, list ordering, and URL maps for 3.2 while 3.0 remains valid.

Operational note: anything keyed off DefaultKernelVersion (e.g. new instances without an image kernel label, shared initrd header selection) will follow 3.2 after deploy; API startup still eagerly ensures every supported kernel for the host arch, so 3.2 adds another required download.

^{Reviewed by Cursor Bugbot for commit 970b672. Bugbot is set up for automated code reviews on this repo. Configure here.}

[kernel-internal]

Would auto-approve: no · high risk · 970b672

Denied: Switches the fleet-wide default guest kernel and rebuilds the shared initrd. A failed artifact download blocks API startup. DKMS/GPU and ARM64 are unverified. This is production rollout of core infrastructure, a denied area.

_{Shadow mode: nothing is auto-approved and a human review is still required. React 👍 or 👎 if this call looks right or wrong.}

[chruffins]

bugs my agent found (don't know how valid these are)

lib/system/manager.go:57 and cmd/api/main.go:340 — EnsureSystemFiles downloads every entry in SupportedKernelVersions at API startup, and main calls os.Exit(1) if any download fails. Registering 3.2 there means every API host fetches the 3.2 kernel for both architectures on boot, and the API won't start if those GitHub assets are unreachable. This contradicts the PR body's "no deployment or default change" and its claim that deployment behavior is unchanged. Either call this out in the PR body and accept it, or keep 3.2 out of the eager loop until something selects it.
lib/system/versions.go:77 — the new KernelHeaderURLs entry is never read for a 3.2 guest. downloadKernelHeaders (lib/system/initrd.go:164) and computeInitrdHash (initrd.go:156) both key on DefaultKernelVersion, so the shared initrd always bundles 3.0 headers, whatever the image label requests. A 3.2 guest running DKMS (vGPU) would build against 3.0 headers. Either select headers per requested kernel, or state that 3.2 isn't DKMS-compatible until the default moves. Both review passes flagged this independently, and I confirmed it in the code.