Move the Linux CI jobs to OSDC runners

[huydhn]

Two changes that have to land together: the runner labels, and the container image they run in.

Labels

From pytorch/pytorch's .github/arc.yaml, applied across the CI and benchmark workflows and to generate_ci_matrix.py's host_machines table, which is where most of them come from:

linux.2xlarge               -> mt-l-x86iavx512-8-64
linux.4xlarge[.memory]      -> mt-l-x86iavx512-16-128
linux.12xlarge[.memory]     -> mt-l-x86iavx512-48-384
linux.24xlarge              -> mt-l-x86iavx512-94-192
linux.24xlarge.memory       -> mt-l-x86iavx512-94-768
linux.arm64.m7g.4xlarge     -> mt-l-arm64g3-16-62
linux.g5.4xlarge.nvidia.gpu -> mt-l-x86aavx2-11-41-a10g

The Graviton 3 choice is preserved — the arm jobs pick that instance for FP16FML, and arm64g3 is the same generation.

Image: amazonlinux:2023 -> almalinux:9

OSDC runs the k8s hook, which streams the workspace into the job container as a tar and extracts it there, rather than the host-side docker cp the EC2 runners used. So the image needs tar and find, and amazonlinux:2023 ships neither:

$ docker run --rm amazonlinux:2023 sh -c 'command -v tar; command -v find'
(neither)

Every job died in prepare-job before its first step — cpToPod timing out thirty times, then find: command not found. Not fixable from a step, since prepare-job runs first.

almalinux:9 is the closest thing to a drop-in:

	tar	find	curl	dnf	libstdc++
amazonlinux:2023	no	no	yes	yes	GLIBCXX_3.4.29
almalinux:9	yes	yes	yes	yes	GLIBCXX_3.4.29

Same RPM family so the scripts' package handling is unchanged, and multi-arch so the arm jobs take the same line.

The pytorch/manylinux2_28-builder images were tried first and are the wrong tool here — they are AlmaLinux 8, and their older libstdc++ fails the conda-installed numpy with GLIBCXX_3.4.29 not found as soon as PyTorch is imported.

Scope

ROCm x86 build hosts move with the rest; the MI350 test jobs keep rocm/dev-ubuntu-22.04 and their own hardware. linux.gcp.a100 and linux.aws.h100 are commented-out future work. The wheel pipelines move in #6320.

[huydhn]

The label mapping here is right, but these jobs cannot move as-is — the container image is the blocker, and it needs fixing before this lands.

amazonlinux:2023 is missing tar and find, both of which the OSDC k8s hook needs inside the job container:

$ docker run --rm amazonlinux:2023 sh -c 'command -v tar; command -v find'
(neither)

That produces the two failures on this PR:

• execCpToPod: exec timed out after 300000ms (×30) — the hook streams the workspace in as a tar and extracts it in the container, the same constraint kubectl cp has. No tar, no copy.
• sh: line 1: find: command not found → prepare-job script failed with exit code 1 — the post-copy hash verification (ACTIONS_RUNNER_COPY_VERIFY_ENABLED=true).

On EC2 this worked because the copy was a docker cp, where the tar work happens host-side and the image never needed either binary.

It cannot be fixed from a workflow step: prepare-job runs before step one, so dnf install findutils tar is too late. It has to be in the image.

Checked the alternatives:

image	tar	find
ubuntu:22.04, debian:bookworm-slim, almalinux:9	yes	yes
quay.io/pypa/manylinux_2_28_x86_64, pytorch/manylinux2_28-builder	yes	yes
amazonlinux:2	no	yes
amazonlinux:2023	no	no

Separately, the ubuntu:22.04 jobs get past prepare-job and then fail at Setup Miniconda, after which every script hits conda: command not found. So a base-image swap alone is not enough; the conda bootstrap needs looking at too.

Suggested order: bake an FBGEMM CI image (with tar, findutils and conda preinstalled — which would also stop every job reinstalling the toolchain), then rebase this label swap on top. #6320 and #6319 do not depend on any of this.

Gotcha written up in pytorch/test-infra#8794.