[release/6.0] x64 on ARM64 fixes #59295
Conversation
* Only set path in x64 mac installer when installing on x64 In other words don't set the path for x64 installer on ARM64 * Remove postinstall script from hostfxr There should be no need for both the host and hostfxr to set the path to dotnet. Since the host installs dotnet, it should be the only package responsible for this. * Make postinstall set install_location on mac Also refactor script to use a template so that we don't need to fork the script. * fix some syntax errors in script * Update src/installer/pkg/sfx/installers/dotnet-host.proj Co-authored-by: Adeel Mujahid <3840695+am11@users.noreply.github.com> * Refine uname regular expressions Co-authored-by: Adeel Mujahid <3840695+am11@users.noreply.github.com>
ericstj
requested review from
jkoritzinsky,
joeloff,
NikolaMilosavljevic,
sfoslund and
hoyosjs
| echo ${InstallerTargetArchitecture}=$INSTALL_DESTINATION | tee -a /etc/dotnet/install_location | ||
|
|
||
| # if we're running on the native architecture | ||
| if [[ "$(uname -m)" =~ "${UnameMachineRegex}" ]]; then |
There was a problem hiding this comment.
uname -m will give you x86_64 under rosetta emulation. Is this the intended behavior?
There was a problem hiding this comment.
If someone is really running this installer package under Rosetta emulation, then yes I think that should be the expected behavior.
There was a problem hiding this comment.
I added a card to our board to test this. I'm not so worried about accidentally setting path, that's easy to fix and user can change it per their intent. I am worried if somehow we can lie to the installer javascript detection, since that would put the files in the wrong place. @sfoslund https://github.com/orgs/dotnet/projects/38#card-69051611
There was a problem hiding this comment.
If someone is really running this installer package under Rosetta emulation, then yes I think that should be the expected behavior.
I believe this is against what was proposed - only setting path of dotnet for the native one. I'm ok with it either way.
There was a problem hiding this comment.
I believe this is against what was proposed - only setting path of dotnet for the native one.
If user’s intention is to “Run as x86_64 app” on arm64 host, in that case “native” is the target of emulation/virtualization and x86_64 behavior is expected. This is how other software (including Apple’s own) handle this case.
There was a problem hiding this comment.
Interesting, I just tried this out and I think I found a way to test it.
If I create a terminal that runs using rosetta, then launch the installer from that ternminal I see it report hw.machine as x86_64 on my M1. This is not good, we don't want the installer to be lied to.
@sfoslund here's the command I ran to do this:
sudo installer -dumplog -verboseR -pkg testPkg.pkg -target /
We should check the newer detection you added and see if that's avoiding this redirection.
There was a problem hiding this comment.
I just tried the repro with latest detection and it also sees the x64 values when run from rosetta terminal.
I found at least one way to identify when this is happening: https://developer.apple.com/documentation/apple-silicon/about-the-rosetta-translation-environment.
sysctl.proc_translated --> this returns 1 when run from rosetta. I wonder if that's a sufficient escape hatch for our purposes.
I opened #59370 to track this.
There was a problem hiding this comment.
This is not good, we don't want the installer to be lied to.
I was considering it as a correct behavior based on how other installers (node.js, rustup and so on) operate in Rosetta2, and more generally, any emulation environments (qemu). Forcing our will against user wishes is no good, IMO.
There was a problem hiding this comment.
Based on my quick research, it looks like we can detect if we're running in rosetta with sysctl -in sysctl.proc_translated. Do we just want to try to block the install in this case? Or should we add this check to our logic for determining if a machine is x64?
There was a problem hiding this comment.
@am11 perhaps you can open an issue with a scenario that you feel is blocked and we can discuss that?
We're actually making the runtime aware of emulation and making it so both x64 and ARM64 can coexist. The problem is that existing installers weren't aware and would clash. We're preserving the single entrypoint, so we do have to make the installers aware of real architecture so that they can avoid clashing. This is the part we can't have lied to, since that circumvents the work. The rest of the runtime is happy to be lied to, that's what the support for this is all about.
|
Could use a check here. I manually updated arcade with darc so that this can merge without conflicts. Feature was approved by tactics for RC2. |
|
Hi folks, this needs a green check so that we can merge it. It's a cherry-pick of the changes approved already in main. Can someone please sign-off? Thanks! |
ghost
locked as resolved and limited conversation to collaborators
This requires dotnet/arcade#7906
Installer work to support x64 on arm64. This is a cherry-pick of all relevant runtime changes.
Customer Impact
Customers want to install our x64 product on arm64 machines in order to run x64 targeted applications.
Testing
We have tested the Windows - runtime consumption of these in main and confirmed it produces installers which behave as we expect. We have tested the changes in isolation as well. It is difficult to test the full end-to-end due to 7.0 not having coherent builds and these changes spanning many repos to realize full end-to-end.
Risk
Low - as designed these changes should not impact existing working scenarios. The risk here is that we have a bug that accidentally impacts those scenarios. We've tried to mitigate that through testing consumption in main. We'll also mitigate by testing bits out of RC2 branches as soon as these changes flow.