feat(nvidia-setup): EKS h100/gb200 → 6.17.0-1019-aws kernel + EFA 1.48.0 - #53
Merged
Conversation
…nd EFA 1.48.0 - Bump eks-h100/eks-gb200 conf defaults to kernel 6.17.0-1017-aws, EFA 1.48.0 - resolve_full_kernel: append the -64k page-size variant on arm64 so GB200 (Grace) installs 6.17.0-1017-aws-64k while H100 stays on 6.17.0-1017-aws. The old *-aws* dedup branch short-circuited the 64k logic, so GB200 was silently getting the non-64k flavor - docs: add 0.4.0 to CHANGELOG, relabel the already-tagged bcm feature as 0.3.0, and add a 0.4.x VERSION_OVERVIEW section
github-actions
Bot
added
doc
📝 WalkthroughWalkthroughThis PR updates EKS GPU kernel and EFA defaults, changes kernel flavor resolution to use architecture-based Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@nvidia-setup/README.md`:
- Line 22: The table entry for GB200 is ambiguous because resolve_full_kernel()
appends "-64k" for arm64; update the table row that currently shows
"6.17.0-1017-aws" to the effective resolved value "6.17.0-1017-aws-64k" (or add
a one-line footnote explaining that resolve_full_kernel() appends "-64k" for
arm64 kernels) so readers see the exact kernel string used by the GB200 support
matrix.
In `@nvidia-setup/VERSION_OVERVIEW.md`:
- Line 26: The new top-level heading "# 0.4.x" should be demoted to a level-2
heading to keep a single H1 in the file; locate the heading text "0.4.x" (and
any other version headings) and replace the leading single "#" with "##" so all
version sections use H2 while preserving the existing single H1 at the top of
VERSION_OVERVIEW.md.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: 2daf74d2-1ce0-418b-88a3-0efc1dbd834b
⛔ Files ignored due to path filters (1)
nvidia-setup/CHANGELOG.mdis excluded by!**/CHANGELOG.md
📒 Files selected for processing (5)
nvidia-setup/README.mdnvidia-setup/VERSION_OVERVIEW.mdnvidia-setup/skyhook_dir/defaults/eks-gb200.confnvidia-setup/skyhook_dir/defaults/eks-h100.confnvidia-setup/skyhook_dir/utilities.sh
1 task
…dpkg errors Bump EKS h100/gb200 kernel defaults from 6.17.0-1017-aws to 6.17.0-1019-aws across defaults, docs, and CHANGELOG. Wrap the kernel apt-get install in apt_install_with_dpkg_heal: on a dpkg error (e.g. dpkg left half-configured / "dpkg was interrupted"), run `dpkg --configure -a` and retry the install once instead of failing the step. Signed-off-by: Alex Yuskauskas <ayuskauskas@nvidia.com>
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
nvidia-setup/README.md (1)
22-22: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winKeep the GB200 entry aligned with the resolved arm64 kernel.
Line 22 still shows
6.17.0-1019-aws, but GB200 resolves to6.17.0-1019-aws-64k. Please show the resolved string here, or add a note that arm64 appends-64k.Proposed fix
-| eks | gb200 | 6.17.0-1019-aws | 1.48.0 | +| eks | gb200 | 6.17.0-1019-aws-64k | 1.48.0 |🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@nvidia-setup/README.md` at line 22, The GB200 README entry is still showing the unresolved kernel string, so update the table row for the gb200 platform to match the actual resolved arm64 kernel name used by the setup flow, or add a note that arm64 appends the -64k suffix. Use the existing GB200/eks README entry as the anchor and keep the documented kernel value aligned with what the resolver returns.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@nvidia-setup/skyhook_dir/steps/install_kernel.sh`:
- Around line 40-61: Tighten the retry condition in apt_install_with_dpkg_heal
so it only triggers on the interrupted-dpkg signatures described in the comment,
not any output containing “dpkg”. Update the grep match in
apt_install_with_dpkg_heal to look for the specific failure phrases (such as
“dpkg was interrupted” or “Sub-process /usr/bin/dpkg returned an error code”)
before running dpkg --configure -a and retrying apt-get install.
---
Duplicate comments:
In `@nvidia-setup/README.md`:
- Line 22: The GB200 README entry is still showing the unresolved kernel string,
so update the table row for the gb200 platform to match the actual resolved
arm64 kernel name used by the setup flow, or add a note that arm64 appends the
-64k suffix. Use the existing GB200/eks README entry as the anchor and keep the
documented kernel value aligned with what the resolver returns.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: 7e8b5433-99ab-4672-bdee-3d93c1c7e2e8
⛔ Files ignored due to path filters (1)
nvidia-setup/CHANGELOG.mdis excluded by!**/CHANGELOG.md
📒 Files selected for processing (6)
nvidia-setup/README.mdnvidia-setup/VERSION_OVERVIEW.mdnvidia-setup/skyhook_dir/defaults/eks-gb200.confnvidia-setup/skyhook_dir/defaults/eks-h100.confnvidia-setup/skyhook_dir/steps/install_kernel.shnvidia-setup/skyhook_dir/utilities.sh
lockwobr
approved these changes
Jul 1, 2026
ayuskauskas
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
6.17.0-1017-awsand EFA1.48.0(skyhook_dir/defaults/eks-h100.conf,eks-gb200.conf).resolve_full_kernelnow appends the-64kpage-size variant on arm64, so GB200 (Grace) installs6.17.0-1017-aws-64kwhile H100 (x86_64) stays on6.17.0-1017-aws. This fixes a latent bug: the old*-aws*dedup branch short-circuited the 64k logic, so GB200 was silently resolving to the non-64k flavor.0.4.0CHANGELOG section; relabel the already-tagged bcm feature as0.3.0 - 2026-05-29(it had been left under[Unreleased]); add a0.4.xsection to VERSION_OVERVIEW.Test Plan
shellcheck skyhook_dir/utilities.sh— cleanresolve_full_kernelunit checks: x86_64 →6.17.0-1017-aws, aarch64 →6.17.0-1017-aws-64k, idempotent when base already ends in-64k