Is this a new feature, an improvement, or a change to existing functionality?
Improvement
How would you describe the priority of this feature request
Medium
Which package does this relate to?
nvidia-setup
Describe the feature, improvement, or change
Two related changes to the kernel-management path so operators can keep nodes on newer AMI kernels instead of force-downgrading, without losing the 64k-page guarantee on arm64:
1. Skip-if-newer install mode (don't downgrade).
Today, when NVIDIA_SETUP_INSTALL_KERNEL=true, apply.sh → ensure_kernel.sh calls install_kernel() unconditionally, and install_kernel.sh always runs downgrade_kernel — it installs the exact pinned kernel and grub-set-defaults to it even if the node booted a newer one. NVIDIA_SETUP_KERNEL_ALLOW_NEWER is only read on the INSTALL_KERNEL=false verify path, so setting it alongside INSTALL_KERNEL=true (as AICR's EKS tuning manifest currently does) has no effect.
Requested behavior: an opt-in mode where the install path first checks the running kernel and skips the install (and the interrupt/reboot) when current ≥ required, only installing when the node is below the pin. That gives "never downgrade, install only when too old" semantics — newer AMI security patches aren't rolled back, and nodes on fresh AMIs skip an install+reboot cycle. Exact-pin behavior should remain the default.
2. Flavor-aware kernel comparison (prerequisite for arm64).
check_kernel_at_least and check_kernel_exact in ensure_kernel.sh compare only the upstream version — the part of uname -r before the first - (deliberately, so ABI suffixes like -1007 vs -1018 don't reverse sort -V ordering). That makes the flavor suffix invisible: on GB200/arm64, a node booted on plain 6.17.0-1019-aws passes a check whose requirement resolves to 6.17.0-1019-aws-64k (via resolve_full_kernel). Under any allow-newer/skip-if-newer mode, a GB200 node would silently run 4k pages — today that's only prevented by the force-install path that change 1 would relax.
Requested behavior: the comparison helpers should also require the running kernel's flavor to match the resolved requirement (e.g. require the -64k suffix when resolve_full_kernel appends it), failing closed on a flavor mismatch even when the version is new enough.
Describe your ideal solution
- New env, e.g.
NVIDIA_SETUP_KERNEL_SKIP_IF_NEWER=true (or extend NVIDIA_SETUP_KERNEL_ALLOW_NEWER to the install path): before downgrade_kernel, run the (flavor-aware) check_kernel_at_least; if it passes, log and exit 0 without installing or requesting an interrupt.
kernel_install_check.sh (post-interrupt check) honors the same mode: accept current ≥ required with matching flavor, instead of requiring exact full-string equality.- Flavor check applies to both the exact and at-least comparisons regardless of mode, so a non-64k kernel on arm64 always fails closed.
Additional context
Context: AICR pins nvidia-setup in its EKS nodewright tuning manifest (currently 0.4.0, NVIDIA/aicr#1599) with NVIDIA_SETUP_INSTALL_KERNEL=true + NVIDIA_SETUP_KERNEL_ALLOW_NEWER=false; the second env is dead there today. The 0.4.0 arm64 -64k resolution fix (#83 lineage) is what makes the flavor-blind comparison newly load-bearing.
Related risk note: EFA installs are generally tolerant of newer -aws kernels (the installer builds the module against running headers and the driver is in-tree), so the main hazards of allow-newer are the untested kernel/driver pairing and the arm64 flavor gap above.
Is this a new feature, an improvement, or a change to existing functionality?
Improvement
How would you describe the priority of this feature request
Medium
Which package does this relate to?
nvidia-setup
Describe the feature, improvement, or change
Two related changes to the kernel-management path so operators can keep nodes on newer AMI kernels instead of force-downgrading, without losing the 64k-page guarantee on arm64:
1. Skip-if-newer install mode (don't downgrade).
Today, when
NVIDIA_SETUP_INSTALL_KERNEL=true,apply.sh→ensure_kernel.shcallsinstall_kernel()unconditionally, andinstall_kernel.shalways runsdowngrade_kernel— it installs the exact pinned kernel andgrub-set-defaults to it even if the node booted a newer one.NVIDIA_SETUP_KERNEL_ALLOW_NEWERis only read on theINSTALL_KERNEL=falseverify path, so setting it alongsideINSTALL_KERNEL=true(as AICR's EKS tuning manifest currently does) has no effect.Requested behavior: an opt-in mode where the install path first checks the running kernel and skips the install (and the interrupt/reboot) when current ≥ required, only installing when the node is below the pin. That gives "never downgrade, install only when too old" semantics — newer AMI security patches aren't rolled back, and nodes on fresh AMIs skip an install+reboot cycle. Exact-pin behavior should remain the default.
2. Flavor-aware kernel comparison (prerequisite for arm64).
check_kernel_at_leastandcheck_kernel_exactinensure_kernel.shcompare only the upstream version — the part ofuname -rbefore the first-(deliberately, so ABI suffixes like-1007vs-1018don't reversesort -Vordering). That makes the flavor suffix invisible: on GB200/arm64, a node booted on plain6.17.0-1019-awspasses a check whose requirement resolves to6.17.0-1019-aws-64k(viaresolve_full_kernel). Under any allow-newer/skip-if-newer mode, a GB200 node would silently run 4k pages — today that's only prevented by the force-install path that change 1 would relax.Requested behavior: the comparison helpers should also require the running kernel's flavor to match the resolved requirement (e.g. require the
-64ksuffix whenresolve_full_kernelappends it), failing closed on a flavor mismatch even when the version is new enough.Describe your ideal solution
NVIDIA_SETUP_KERNEL_SKIP_IF_NEWER=true(or extendNVIDIA_SETUP_KERNEL_ALLOW_NEWERto the install path): beforedowngrade_kernel, run the (flavor-aware)check_kernel_at_least; if it passes, log and exit 0 without installing or requesting an interrupt.kernel_install_check.sh(post-interrupt check) honors the same mode: accept current ≥ required with matching flavor, instead of requiring exact full-string equality.Additional context
Context: AICR pins nvidia-setup in its EKS nodewright tuning manifest (currently 0.4.0, NVIDIA/aicr#1599) with
NVIDIA_SETUP_INSTALL_KERNEL=true+NVIDIA_SETUP_KERNEL_ALLOW_NEWER=false; the second env is dead there today. The 0.4.0 arm64-64kresolution fix (#83 lineage) is what makes the flavor-blind comparison newly load-bearing.Related risk note: EFA installs are generally tolerant of newer
-awskernels (the installer builds the module against running headers and the driver is in-tree), so the main hazards of allow-newer are the untested kernel/driver pairing and the arm64 flavor gap above.