Skip to content

fix(nvidia-mig-manager): select package matching target architecture - #1399

Open
100milliongold wants to merge 1 commit into
NVIDIA:masterfrom
xiilab:fix/mig-manager-arch-aware-urls
Open

fix(nvidia-mig-manager): select package matching target architecture#1399
100milliongold wants to merge 1 commit into
NVIDIA:masterfrom
xiilab:fix/mig-manager-arch-aware-urls

Conversation

@100milliongold

Copy link
Copy Markdown
Contributor

Problem

roles/nvidia-mig-manager/defaults/main.yml pins both package URLs to x86_64:

mig_manager_url_deb: .../nvidia-mig-manager_0.14.2-1_amd64.deb
mig_manager_url_rpm: .../nvidia-mig-manager-0.14.2-1.x86_64.rpm

On aarch64 the download either 404s or installs a package dpkg/rpm rejects
for the wrong architecture, so MIG configuration never comes up on ARM nodes
(GH200, Grace-Hopper).

Change

Build both URLs from ansible_architecture.

The two asset families spell the architecture differently, so they need separate
maps — the .deb uses Debian names and the .rpm uses kernel names:

ansible_architecture .deb token .rpm token
x86_64 amd64 x86_64
aarch64 arm64 aarch64

arm64 is accepted as an input value to match existing repository practice:
roles/nvidia-dgx/vars/ubuntu-24.04.yml:2 already tests
ansible_architecture in ['aarch64', 'arm64'].

An unlisted architecture is passed through unchanged, which yields a URL for an
asset that does not exist — v0.14.2 publishes only x86_64 and aarch64 (.deb,
.rpm, .tar.gz for each). The download then fails with a clear 404 instead of
installing a package built for the wrong architecture, and MIG-capable hardware
is limited to those two architectures in any case.

The version and release number are also lifted into their own variables. This is
outside the architecture change, and the reason is duplication: the two URLs
repeat the version four times between them, so a bump previously meant editing
four places in two lines. x86_64 resolves to the same two URLs as before.

Verification

Asset names read from the release itself:

$ gh api repos/NVIDIA/mig-parted/releases/tags/v0.14.2 --jq '.assets[].name'
nvidia-mig-manager-0.14.2-1.aarch64.rpm
nvidia-mig-manager-0.14.2-1.x86_64.rpm
nvidia-mig-manager_0.14.2-1_amd64.deb
nvidia-mig-manager_0.14.2-1_arm64.deb
...

All four rendered URLs return HTTP 206 to a ranged request (the redirect target
serves partial content):

HTTP/2 206 · nvidia-mig-manager_0.14.2-1_amd64.deb
HTTP/2 206 · nvidia-mig-manager_0.14.2-1_arm64.deb
HTTP/2 206 · nvidia-mig-manager-0.14.2-1.x86_64.rpm
HTTP/2 206 · nvidia-mig-manager-0.14.2-1.aarch64.rpm

Both download URLs were pinned to x86_64, so on aarch64 the task either got a
404 or installed a package dpkg/rpm rejects for the wrong architecture, and MIG
configuration never came up on ARM nodes.

Build the URLs from ansible_architecture. The two asset families spell the
architecture differently -- the .deb uses Debian names (amd64/arm64) and the
.rpm uses kernel names (x86_64/aarch64) -- so they need separate maps. arm64 is
accepted as an input value to match roles/nvidia-dgx/vars/ubuntu-24.04.yml,
which already tests for both spellings.

An unlisted architecture is passed through unchanged and yields a URL for an
asset that does not exist; v0.14.2 publishes only x86_64 and aarch64. The
download then fails with a clear 404 rather than installing a package built for
another architecture.

The version and release number move into their own variables because the two
URLs repeated the version four times between them.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants