Support Rocky Linux 10 / RHEL 10 in nvidia-tuned

[lockwobr]

Is this a new feature, an improvement, or a change to existing functionality?

New feature

Which package does this relate to?

nvidia-tuned

Please provide a clear description of the problem this feature solves

RHEL 10 shipped in May 2025 and Rocky Linux 10 followed; rockylinux/rockylinux:10 is currently at 10.2 (2026-05-25). nvidia-tuned ships OS-specific profiles for rhel/9 only.

detect_os in nvidia-tuned/skyhook_dir/prepare_nvidia_profiles.sh reduces RHEL-family IDs to their major version:

case "$OS_ID" in
    rhel|centos|rocky|almalinux|amzn)
        VERSION=$(echo "$VERSION" | cut -d. -f1)
        ;;
esac

So a Rocky 10 host resolves profiles/os/rhel/10/, finds nothing, and silently falls back to profiles/os/common/. The README's support table marks that fallback path untested:

| Other | Any | ⚠️ Fallback | Falls back to os/common/ profiles (untested, requires tuned >= 2.19) |

Nothing in tests/integration/nvidia_tuned/__init__.py's TEST_MATRIX covers an RHEL-family OS without a version-specific profile directory, so the first signal that this fallback broke would come from a user rather than CI.

Feature Description

Decide and document whether RHEL / Rocky 10 is a supported platform for nvidia-tuned, and cover the resulting behaviour in CI.

Describe your ideal solution

If RHEL/Rocky 10 is supported:

1. Add a row for it to the OS support table in nvidia-tuned/README.md.
2. Add profiles/os/rhel/10/ if it needs anything beyond the common profiles (it may not; rhel/9 is currently empty of per-accelerator overrides).
3. Add rockylinux/rockylinux:10 to TEST_MATRIX in tests/integration/nvidia_tuned/__init__.py.

If it is not supported, say so explicitly in the support table, so falling back to os/common/ is a documented outcome rather than an accident.

Either way this is cheap to test now: as of #115 the matrix is sharded per base image, so an extra OS costs one parallel CI job of roughly 40-55s rather than serial minutes.

Describe any alternatives you have considered

Adding rockylinux:10 to the test matrix alone. This is not enough on its own: without a support decision it just asserts that the untested fallback happens to work today, which is not the same as supporting the platform.

Additional context

Related, and arguably more urgent: the current matrix entry is rockylinux:9, which resolves to Docker Hub's library/rockylinux. That repository looks frozen: its newest tag is 9.3.20231119 (November 2023). The maintained image is rockylinux/rockylinux:9, currently 9.8 (2026-05-25).

So the Rocky base layer under test is roughly 2.5 years stale, which cuts against the "keeping software current" guidance in AGENTS.md. The impact is partly masked because dnf install tuned pulls from live repositories at build time, so the test image still gets a current tuned (2.27.0), but the base OS layer itself is not current.

Switching rockylinux:9 to rockylinux/rockylinux:9 is a one-line change. baked_tag in tests/helpers/base_images.py already handles the slash in a namespaced image correctly, and there is a test covering exactly that case.

[efegokdemir]

/assign