Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The "--use-current-runtime" option doesn't work correctly in Arm-based musl system (Alpine) #28809

Closed
mthalman opened this issue Oct 28, 2022 · 9 comments

Comments

@mthalman
Copy link
Member

The --use-current-runtime option should make use of the current system's RID. This is not working currently when that system is on the Arm architecture and musl-based. I specifically used Alpine. Not sure if it's all musl systems or just specific to Alpine since Alpine has its own RID. It's essentially treating it as a non-musl-based system. In other words, it's deriving the RID as linux-arm64 instead of linux-musl-arm64. What's interesting is that this only occurs for Arm64/Arm32 but not x64.

This can be shown in two ways using the dotnet restore and dotnet publish commands.

Repro steps

  1. Install .NET 7 RC2 SDK
  2. Verify RID by running dotnet --info:
.NET SDK:
 Version:   7.0.100-rc.2.22477.23
 Commit:    0a5360315a

Runtime Environment:
 OS Name:     alpine
 OS Version:  3.16
 OS Platform: Linux
 RID:         alpine.3.16-arm64
 Base Path:   /usr/share/dotnet/sdk/7.0.100-rc.2.22477.23/

Host:
  Version:      7.0.0-rc.2.22472.3
  Architecture: arm64
  Commit:       550605cc93

.NET SDKs installed:
  7.0.100-rc.2.22477.23 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 7.0.0-rc.2.22476.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 7.0.0-rc.2.22472.3 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download
  1. Create a simple console app: dotnet new console
  2. Restore the project: dotnet restore --use-current-runtime -v normal

Notice in the output that package names are not specific to musl when they should be. For example, linux-arm64 should be linux-musl-arm64 in this output:

GET https://api.nuget.org/v3-flatcontainer/microsoft.netcore.app.runtime.linux-arm64/7.0.0-rc.2.22472.3/microsoft.netcore.app.runtime.linux-arm64.7.0.0-rc.2.22472.3.nupkg
  1. Restore again, this time explicitly specifying the RID: dotnet restore -r linux-musl-arm64
  2. Now attempt to publish using the --use-current-runtime option: dotnet publish -c Release -o /app --use-current-runtime --no-restore

And you get this error because it's trying to use linux-arm64 instead of linux-musl-arm64:

/usr/share/dotnet/sdk/7.0.100-rc.2.22477.23/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error NETSDK1047: Assets file '/source/obj/project.assets.json' doesn't have a target for 'net7.0/linux-arm64'. Ensure that restore has run and that you have included 'net7.0' in the TargetFrameworks for your project. You may also need to include 'linux-arm64' in your project's RuntimeIdentifiers. [/source/aspnetapp.csproj]

If you just use --use-current-runtime for all these steps and ignore the fact it's not doing the right stuff, the app won't run because it's not using the correct bits for the system it's running on. You end up getting this fun error when attempting to run the app:

standard_init_linux.go:228: exec user process caused: no such file or directory
@dotnet-issue-labeler
Copy link

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

@ghost ghost added the untriaged Request triage from a team member label Oct 28, 2022
@mthalman mthalman transferred this issue from dotnet/runtime Oct 28, 2022
@nagilson
Copy link
Member

This was going to be fixed by dotnet/installer#14637 but now it's going to be fixed by dotnet/installer#14647 (thank you @baronfel). The implicit SDK Rid is also using the same portableSDKRid as UCR so this is concerning.

@nagilson nagilson removed the untriaged Request triage from a team member label Oct 28, 2022
@mthalman
Copy link
Member Author

@nagilson - Does that mean it will be fixed in the GA release of 7.0?

@nagilson
Copy link
Member

@mthalman I would hope so, but we are running out of time, or have already ran out of time, for fixes in GA. Probably the former. @tmds Was this fix planned for GA?

cc @mmitche

@mmitche
Copy link
Member

mmitche commented Oct 28, 2022

@mthalman I would hope so, but we are running out of time, or have already ran out of time, for fixes in GA. Probably the former. @tmds Was this fix planned for GA?

cc @mmitche

We have definitely run out of time for GA. But this could be fixed in 7.0.1

@am11
Copy link
Member

am11 commented Oct 30, 2022

The --use-current-runtime option should make use of the current system's RID. This is not working currently when that system is on the Arm architecture and musl-based.

I am actually using --use-current-runtime on musl arm64 for a while with net6.0 earliest RTM in a build machine. This regression was introduced in #22373 which I noticed a few weeks ago #22373 (comment) when testing upgrades with 7.0.0-rc2. We should backport the regression fix to 6.x as well.

@ayakael
Copy link
Contributor

ayakael commented Nov 11, 2022

FYI, the dotnet6 and dotnet7 (to be released soon) Alpine packages have thoses fixes integrated.

@ztatw
Copy link

ztatw commented Jul 8, 2023

I tried dotnet/sdk-6.0-alpine and dotnet/sdk-7.0-alpine in Ubuntu-22.04-arm64, only 7.0 sdk can find correct linux-musl-x64

I also tried the dotnet/sdk-6.0-alpine in Ubuntu-22.04-amd64, it works fine, compared with in Ubuntu-22.04-arm64, they use same dotnet cli version(6.0.411)

image
image

@mthalman
Copy link
Member Author

Not exactly sure which 7.0 patch release this was fixed in but it's fixed now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants