SH installs wrong architecture on ARM64 host, ARM32 OS

[directhex]

Issue Description

get_machine_architecture contains the following:

https://github.com/microsoft/azure-pipelines-tasks/blob/08914a70defbdbe73b2bb87e8d0663bdbeb248e0/Tasks/UseDotNetV2/externals/get-os-distro.sh#L159-L178

This is... fundamentally not how uname should be used.

1. uname refers to the profile of the running kernel, not the executing environment. It can be a 100% mismatch, and that's valid and fine. The .NET Core environment which gets installed needs to match the executing environment, not the kernel.

Some examples:

(xenial-armhf)root@xam-softiron-16:/# uname -a
Linux xam-softiron-16 4.15.0-50-generic dotnet/cli#54~16.04.1-Ubuntu SMP Wed May 8 15:55:41 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux
(xenial-armhf)root@xam-softiron-16:/# file /bin/bash
/bin/bash: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib, for GNU/Linux 3.2.0, BuildID[sha1]=9a214a5bbfe98a862fd835fdcbfa1d9f8dabff0e, stripped

root@breakfast:/# uname -a
Linux breakfast 4.15.0-50-generic dotnet/cli#54-Ubuntu SMP Mon May 6 18:46:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
root@breakfast:/# file /bin/bash 
/bin/bash: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib, for GNU/Linux 3.2.0, BuildID[sha1]=d3d60e9d8193746d270cd74bcb2f5742ffc65d48, stripped

In both these cases, these are 64-bit kernels with 32-bit executing environments. There is no guarantee that 64-bit libraries are available to execute 64-bit code, and it is a 32-bit .NET Core which should be installed.

2. armv7l is not the only valid uname which requires a 32-bit .NET Core. 32-bit compatibility kernel profile on 64-bit ARM kernels will show armv8l:

$ uname -a
Linux xam-softiron-15 4.15.0-50-generic dotnet/cli#54~16.04.1-Ubuntu SMP Wed May 8 15:55:41 UTC 2019 armv8l armv8l armv8l GNU/Linux

ref: microsoft/azure-pipelines-tasks#10439

[johnbeisner]

@directhex
'get-os-distro.sh' appears to be a partial copy of https://dot.net/v1/dotnet-install.sh
https://dot.net/v1/dotnet-install.sh and https://dot.net/v1/dotnet-install.ps1 are supported by the CLI team and .Net core as an SDK acquisition method. More to the point, https://dot.net/v1/dotnet-install.sh has an 'architecture' parameter expressly for the situation you have described. Please try this command:
./dotnet-install.sh --architecture arm
Let me know if this works for you.

[directhex]

The --architecture override works, but the auto-detection should still be corrected.

dotnet: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=e152ba87e063bbbf82e6dd5a94959d433b1661e1, stripped

Also, I don't think it can be passed through if installing via the Arcade eng/common/tools.sh wrapper?

[marek-safar]

@livarcocc is this something what will be addressed or we need to work on a workaround?

[directhex]

My suspicion that this prevents use of Arcade is correct. The InitializeDotNetCli function does not pass through the architecture (you'd need to bypass it and call into InstallDotNetSdk directly, which opens another can of worms)

Rather than add workarounds to Arcade, I feel it should be fixed properly, here.

[bishal-pdMSFT]

'get-os-distro.sh' appears to be a partial copy of https://dot.net/v1/dotnet-install.sh
https://dot.net/v1/dotnet-install.sh and https://dot.net/v1/dotnet-install.ps1 are supported by the CLI team and .Net core as an SDK acquisition method

@johnbeisner @livarcocc yes, you are right. 'get-os-distro.sh' is a partial copy which uses install scripts as a reference.

More to the point, https://dot.net/v1/dotnet-install.sh has an 'architecture' parameter expressly for the situation you have described. Please try this command:
./dotnet-install.sh --architecture arm

This will require all tools depending on the install scripts to expose additional parameter for architecture. Please note that the default behavior still will be different for windows and linux. dotnet-install.ps1 installs as per process architecture and dotnet-install.sh installs as per kernel architecture. For default inputs, these two should be consistent.

[bishal-pdMSFT]

@johnbeisner any comment on this thread? Are you planning to make changes to ensure that both Windows and Linux install for same architecture? This will ensure that downstream tools won't have to tke care of this.

[hiyadav]

@livarcocc is this something what will be addressed or we need to work on a workaround?

Hey,
Is there a plan for this, is this getting addressed soon ?

[AR-May]

There are two failure cases in the issue:
• The kernel is 64-bit, the kernel truthfully reports that it is 64-bit, but the OS is 32-bit
• The kernel is 64-bit, the kernel lies and reports that it is 32-bit, but the OS is 32-bit
After the discussion with the team, we came to the decision not to fix the first case. The install scripts are going to a maintenance mode and this one does not seem a high priority point of this issue at the moment.
The second case was fixed by PR #111.