Runtime: .NET Core 2.2 alpine images have 'unknown' rid

[MichaelSimons]

@tmds commented on Sat Dec 22 2018

.NET Core 2.2 alpine images use alpine 3.8. This rid isn't in the .NET Core 2.2 rid graph.
This causes .NET Core to fall back to the linux-x64 rid.
This may cause issues in particular because linux-x64 implies glibc, and alpine uses musl.

---

@MichaelSimons commented on Wed Jan 02 2019

This is an issue with the RID graph in CoreFx. Moving issue.

[ektrah]

This is also the problem in https://github.com/dotnet/coreclr/issues/20952.

[am11]

I think in case of v3.8 or future version of Alpine Linux, it should use linux-musl-x64 identifier, since v2.1 of .NET Core: https://github.com/dotnet/corefx/pull/28560.

These RIDs were adapted across the board (dotnet/aspnet and other upstream repos like: https://github.com/ericsink/SQLitePCL.raw on which ASP.NET has dependency on).

Over at Void Linux (musl-libc edition), we are getting the same linux-musl-x64 https://github.com/dotnet/corefx/issues/34239.

To test it on Alpine:

#!/usr/bin/env sh

dotnet new console -n hwApp
cd hwApp

# should publish
dotnet publish -r linux-musl-x64 -o ~/hw-musl

# should publish (note, event it's for glibc, it will download runtime packages and publish the app)
dotnet publish -r linux-x64 -o ~/hw-glibc

# should work
~/hw-musl/hwApp

# should NOT work
~/hw-glibc/hwApp

# lets inspect the reason why:
apk add binutils

readelf -l ~/hw-glibc/hwApp | grep Requesting
#       [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
# which does not exist on strictly muscle libC based system

vs.

readelf -l ~/hw-musl/hwApp | grep Requesting
#       [Requesting program interpreter: /lib/ld-musl-x86_64.so.1]

for Void Linux (musl edition), ditto steps except the package manager is different xbps-install binutils instead of apk add binutils.

[tmds]

@am11 it works when you publish up front to a compatible rid. .NET Core doesn't figure out it should prefer musl over glibc for unknown Alpine versions.

[am11]

@tmds, good point. To test whether it works in 2.2 Alpine docker, we could create a nuget package with only Alpine 3.8 and/or 3.9 native deps say, C-libgethelloworld (resolver mustn't know about unreleased versions of OS either 😄), and restore from local filesystem-based repo.

I read some related points in @eerhardt's post: https://github.com/dotnet/core-setup/issues/1846. Looks like we have a way to override the RID using environment variable DOTNET_RUNTIME_ID=linux-musl-x64 (which official 3.8 Dockerfile can define): https://github.com/dotnet/core-setup/blob/dbb1c1e5/src/corehost/cli/deps_format.cpp#L138-L163, but it would be also good if implementation insert musl there as well, e.g. in CMAKE:

# to accommodate future versions of alpine and other musllibc-based distros
execute_process (
    COMMAND ldd --version 2>&1 | grep musl
    OUTPUT_VARIABLE CLR_CMAKE_MUSL_LIBC_PLATFORM
)

and wire the #define in C++ code to insert the value in the construction of RID and in fallback RID. The fallback RID currently does not account for non-glibc Linux (or Berkeley distros): https://github.com/dotnet/core-setup/blob/c90e8d7e/src/corehost/common/pal.h#L61-L72, where the proposed CLR_CMAKE_MUSL_LIBC_PLATFORM could be used.

[eerhardt]

@steveharter @jeffschwMSFT @vitek-karas - for thoughts on changing the fallback RID calculation for musl based distros. (It makes sense to me.)

IMO - the root issue here is that RIDs are supposed to be opaque strings, but that design doesn't scale/work in the Linux/Unix distro world. See https://github.com/NuGet/Home/issues/5862 which describes the issue perfectly. However that issue has gotten zero traction and is 1.5 years old.

/cc @ericstj @rrelyea

[tmds]

@joperezr Microsoft Alpine .NET Core 2.2 images are based on Alpine 3.8. Because 3.8 isn't in the 2.2 rid graph, weird issues will happen.

[eerhardt]

IMO - at a minimum we need to add alpine 3.8 to the RID graph for 3.0. And we probably need to be adding it to the RID graph for 2.1 and 2.2 since we claim we support "Alpine Linux 3.7 or later versions" (see Linux Prerequisites).

Without this RID in the graph, we are not supporting Alpine 3.8.

[MichaelSimons]

As @eerhardt mentions, Alpine 3.7+ is our official support statement for 2.* and 3.0 therefore it seems pertinent that this issue is addressed.

cc @richlander, @leecow

[joperezr]

Marking it as 3.0 for now to get the fix on master. Once we have that we can submit this for consideration to shiproom for backporting it to 2.1 and 2.2

[richlander]

Please do fix this. We're now looking at adopting Alpine 3.9, soonish.

https://twitter.com/alpinelinux/status/1086359769730957312

[MichaelSimons]

FYI - Alpine 3.9 is just around the corner as well.

[karelz]

It has been fixed in 2.1.9 via PR dotnet/corefx#34789.
It has been fixed in ~2.2.3~ 2.2.5 via commit 99d81d17cf2d794c9ae839dd5f5eb928b9d995a3 (the commit happened earlier, but due to packaging issues it didn't really ship until 2.2.5 - see https://github.com/dotnet/corefx/issues/34316#issuecomment-485908686 for details)

[bording]

@karelz Looks like the changes didn't actually make it into a 2.2 release yet: https://github.com/dotnet/sdk/issues/3037#issuecomment-481902382

[ctaggart]

It is still broken in 2.2.203-alpine3.9. You can see the RID with dotnet --info. It should print alpine.3.9-x64 instead of linux-musl-x64. We were hoping we could override the value by setting DOTNET_RUNTIME_ID, but that does work either. Native library loading that depends on RIDs is broken.

PS C:\Users\taggac\github\Nerdbank.GitVersioning> docker run --name nbgv -it --rm -v ${PWD}:/src -w /src -e DOTNET_RUNTIME_ID=alpine.3.9-x64 mcr.microsoft.com/dotnet/core/sdk:2.2.203-alpine3.9
/src # dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   2.2.203
 Commit:    e5bab63eca

Runtime Environment:
 OS Name:     alpine
 OS Version:  3.9
 OS Platform: Linux
 RID:         linux-musl-x64
 Base Path:   /usr/share/dotnet/sdk/2.2.203/

Host (useful for support):
  Version: 2.2.4
  Commit:  f95848e524

.NET Core SDKs installed:
  2.2.203 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.2.4 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.2.4 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.2.4 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

[joperezr]

This will get fixed in the upcomming 2.2 release (2.2.5). Even though this got checked in for 2.2.3, there was a problem with our Platforms package that has now been addressed. 2.2.5 will contain the fix for this.

[karelz]

Thanks @joperezr! Info above updated. Did the 2.1.9 happen normally or is that in later version as well?

[joperezr]

Yes, 2.1.9 does have the right change(I just re-verified 😄). This problem with the Platforms package only affected release/2.2 branch.

[karelz]

Thanks for confirmation @joperezr!

[adnan-kamili]

https://github.com/dotnet/runtime/issues/11453#issuecomment-642604839

[kleisauke]

This seems to have regressed again in mcr.microsoft.com/dotnet/core/sdk:3.1-alpine3.12, see:

Details

$ docker run -it mcr.microsoft.com/dotnet/core/sdk:3.1-alpine3.12 dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.1.301
 Commit:    7feb845744

Runtime Environment:
 OS Name:     alpine
 OS Version:  3.12
 OS Platform: Linux
 RID:         linux-musl-x64
 Base Path:   /usr/share/dotnet/sdk/3.1.301/

Host (useful for support):
  Version: 3.1.5
  Commit:  65cd789777

.NET Core SDKs installed:
  3.1.301 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.1.5 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.5 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download
$ docker run -it mcr.microsoft.com/dotnet/core/sdk:3.1-alpine3.11 dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.1.301
 Commit:    7feb845744

Runtime Environment:
 OS Name:     alpine
 OS Version:  3.11
 OS Platform: Linux
 RID:         alpine.3.11-x64
 Base Path:   /usr/share/dotnet/sdk/3.1.301/

Host (useful for support):
  Version: 3.1.5
  Commit:  65cd789777

.NET Core SDKs installed:
  3.1.301 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.1.5 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.5 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

This command:

$ docker run -it mcr.microsoft.com/dotnet/core/sdk:3.1-alpine3.12 dotnet --info

Should print:

RID:         alpine.3.12-x64

This regression causes native NuGet binaries to be copied from the runtimes/linux-x64/native/* directory instead than from runtimes/linux-musl-x64/native/*, leading to P/Invoke failures. Note that setting the DOTNET_RUNTIME_ID environment variable to linux-musl-x64 fixes this. For example:

FROM mcr.microsoft.com/dotnet/core/sdk:3.1-alpine3.12 AS build

ENV DOTNET_RUNTIME_ID=linux-musl-x64

[MichaelSimons]

@kleisauke, Can you log a new issue for this please?

[richlander]

This is what I see:

PS D:\git\iot-official\samples\shift-register> docker run -it mcr.microsoft.com/dotnet/core/sdk:3.1-alpine3.12 dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.1.301
 Commit:    7feb845744

Runtime Environment:
 OS Name:     alpine
 OS Version:  3.12
 OS Platform: Linux
 RID:         linux-musl-x64
 Base Path:   /usr/share/dotnet/sdk/3.1.301/

I would expect the most-specific RID to be printed, however, the RID I see here should provide the behavior you want. No?

[xakep139]

Is this issue somehow connected with https://github.com/dotnet/sdk/issues/12110?