[Fairuzan Roslan (fairuzan)]

Problem

src/oryx/install.sh always publishes Oryx with -r linux-x64, so on arm64 hosts the feature installs successfully but leaves an x86-64 binary that cannot run:

$ file /usr/local/buildscriptgen/GenerateBuildScript
ELF 64-bit LSB pie executable, x86-64, ..., interpreter /lib64/ld-linux-x86-64.so.2

$ oryx --version
rosetta error: failed to open elf at /lib64/ld-linux-x86-64.so.2

(On native arm64 Linux this shows up as exec format error instead of the Rosetta error from Docker Desktop on Apple silicon.)

This is currently one of the blockers for an arm64 build of mcr.microsoft.com/devcontainers/universal. When I built src/universal natively on arm64, all 10 Oryx-related checks in its test-project/test.sh failed for this reason. See also devcontainers/images#1604.

Changes

• Map dpkg --print-architecture to the matching .NET runtime identifier (amd64 → linux-x64, arm64 → linux-arm64) and use it for both dotnet publish calls. Unsupported architectures fail early with the same (!) Architecture ... unsupported message the hugo/php/ruby features use.
• Add an oryx-binary-matches-architecture test that reads the ELF e_machine field of GenerateBuildScript and compares it to uname -m. oryx --version alone can miss a mismatch when QEMU or Rosetta emulation is available.
• Bump the version from 2.0.2 to 2.0.3.

On amd64 the published runtime identifier is still linux-x64, so the build output there doesn't change.

Testing

devcontainer features test --features oryx --project-folder . run natively on arm64 (Apple silicon, Docker Desktop 29.9.2, aarch64 Linux VM):

================== TEST REPORT ==================
✅ Passed:      'oryx'
✅ Passed:      'install_dotnet_and_oryx'
✅ Passed:      'install_older_dotnet_and_oryx'
✅ Passed:      'install_prev_dotnet_and_oryx'
✅ Passed:      'test_python_project'

including:

🔄 Testing 'Oryx version'
✅  Passed 'Oryx version'!
🔄 Testing 'oryx-binary-matches-architecture'
✅  Passed 'oryx-binary-matches-architecture'!

After the change:

$ file /usr/local/buildscriptgen/GenerateBuildScript
ELF 64-bit LSB pie executable, ARM aarch64, ..., interpreter /lib/ld-linux-aarch64.so.1

I also swapped an arm64 build of Oryx into the universal image. oryx --version, oryx build of the Python sample, and oryx prep all work there.

I did not test on amd64 locally. CI on this PR covers that path.

Known limitation (out of scope)

This fixes the Oryx CLI itself. Separately, the SDKs that oryx prep / dynamic install download from https://oryx-cdn.microsoft.io are x86-64 builds regardless of host architecture. On arm64 the downloaded /opt/nodejs/20.11.0/bin/node and /opt/php/8.1.30/bin/php are x86-64 and fail to execute. The existing *-installed-by-oryx checks still pass because they only list /opt/<platform> and don't run the binaries. Fixing that needs arm64 SDK builds on the Oryx side (microsoft/Oryx), so it isn't part of this PR.

[Fairuzan Roslan (fairuzan)]

@microsoft-github-policy-service agree