sdk: dotnet restore fails on Linux 4.6.2

And this here is exactly why we have been pleading for an official fix. It cannot be reasonably expected for normal users to compile some native app from source and repackage it with all the tooling to create a fix for themselves.

Every day this stays unresolved it gets more embarrassing. And it starts to become writing on the wall for our trust concerning swift resolve the next time an issue like this comes up.

It has been more than a few weeks ago since I got the coreclr guys to push the fix into the main branch and it has been more than 3 months ago since similar issues started to crop up.

Is this what we’ll have to get used to when it comes to support for a now opensource .net? As we as a community cannot change the links on http://dot.net to point to a new release, or even create a release for that matter. Either do full public community governance or be prepared to do this kind of work yourself within a normal timeframe.

It amazes me, really…

Thanks @viktorbk that has helped resolve the issue/work around it. If anyone uses Gitlab (or maybe other CI services that use YAML), this is my definition:

job_build_dotnet:
       stage: build
       image: microsoft/dotnet:latest
       script:
         - apt-get update
         - apt-get install unzip
         - mkdir tmp-update && cd tmp-update
         - wget https://www.nuget.org/api/v2/package/runtime.ubuntu.14.04-x64.Microsoft.NETCore.Runtime.CoreCLR/1.0.4
         - mv 1.0.4 tmp.zip
         - unzip tmp.zip
         - cp ./runtimes/ubuntu.14.04-x64/lib/netstandard1.0/* /usr/share/dotnet/shared/Microsoft.NETCore.App/1.0.0
         - cp ./runtimes/ubuntu.14.04-x64/native/* /usr/share/dotnet/shared/Microsoft.NETCore.App/1.0.0
         - cd ..
         - dotnet restore
         - dotnet publish src/FakeNameHere.Web
       artifacts:
         expire_in: 12 hrs
         paths:
          - src/FakeNameHere.Web/bin/Debug/netcoreapp1.0/publish/

job_build_docker:
       stage: deploy
       image: docker:latest
       services:
        - docker:dind
       script:
        - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.gitlab.com/yetanotherchris/FakeNameHere 
        - docker build -t registry.gitlab.com/yetanotherchris/FakeNameHere:latest .
        - docker push registry.gitlab.com/yetanotherchris/FakeNameHere:latest
       dependencies:
        - job_build_dotnet

For ubuntu 14.04: mkdir tmp-update && cd tmp-update wget https://www.nuget.org/api/v2/package/runtime.ubuntu.14.04-x64.Microsoft.NETCore.Runtime.CoreCLR/1.0.4 mv 1.0.4 tmp.zip unzip tmp.zip sudo cp ./runtimes/ubuntu.14.04-x64/lib/netstandard1.0/* /usr/share/dotnet/shared/Microsoft.NETCore.App/1.0.0 sudo cp ./runtimes/ubuntu.14.04-x64/native/* /usr/share/dotnet/shared/Microsoft.NETCore.App/1.0.0 then dotnet restore works

@viktorbk, nice! Maybe use which to make script install-dir agnostic, like:

d1=$(dirname $(which dotnet))/shared/Microsoft.NETCore.App/1.0.0

sudo cp ./runtimes/ubuntu.14.04-x64/lib/netstandard1.0/* ./runtimes/ubuntu.14.04-x64/native/* $d1
# cp is capable of handling multi-source, single-target

We’re actively working on unblocking and much of the sentiment here is well founded. Very sorry for all the delays on this. We are definitely interested in making sure the community is able to get new builds with fixes and unblock and we’re invested in making that a reality. Talk to @ellismg for more details.

For this issue, we’re going to very shortly publish steps for how to manually patch your install with the binaries from the released nuget packages. That is the first step to unblocking folks. We’re actively building those instructions now.

After that, we’re going to get an updated installer people can use that will install these updated bits and the CLI will start running on those.

Last step will be updating the installers at dot.net to have the fix by default.

I’m seeing this on Linode. Very frustrating. What’s the plan here, this is two months old.

scott@ubuntu:~# uname -r
4.6.3-x86_64-linode70

@tanordheim, dotnet/coreclr#6027 is a link of PR, the in-tree commit of master branch is dotnet/coreclr@56ab756.

You most probably only need to replace mscorlib, libcoreclr, and system.private.corlib (in total 5 items, see below) from the build output and replace with the installed one. Here is how:

# this is std Bourne shell
git clone https://github.com/dotnet/coreclr -b release/1.0.0

cd coreclr

git cherry-pick 56ab756
git cherry-pick 41912e3  # you *may* need this patch as well,
                         # see https://github.com/dotnet/coreclr/issues/5006

build.sh release

# it may ask you to install cmake, libunwind etc. if you haven't already,

# On successful build, time to copy stuff:

# 1)

# make backup of existing libcoreclr.so in the installed runtime dir first:
mv $(dirname $(which dotnet))/shared/Microsoft.NETCore.App/1.0.0/libcoreclr.so \
$(dirname $(which dotnet))/shared/Microsoft.NETCore.App/1.0.0/libcoreclr.so.old
# ^ this way, you can always move `libcoreclr.so.old` back to `libcoreclr.so`

# copy newly built libcoreclr.so over to the installed runtime dir
cp bin/Product/Linux.x64.Release/libcoreclr.so \
$(dirname $(which dotnet))/shared/Microsoft.NETCore.App/1.0.0/

# 2)

# similarly, make backup of existing mscorlib.dll in the installed runtime dir:
mv $(dirname $(which dotnet))/shared/Microsoft.NETCore.App/1.0.0/mscorlib.dll \
$(dirname $(which dotnet))/shared/Microsoft.NETCore.App/1.0.0/mscorlib.dll.old

# copy newly built mscorlib.dll over to the installed runtime dir
cp bin/Product/Linux.x64.Release/mscorlib.dll \
$(dirname $(which dotnet))/shared/Microsoft.NETCore.App/1.0.0/

# repeat for the following:

# 3) bin/Product/Linux.x64.Release/mscorlib.ni.dll
# 4) bin/Product/Linux.x64.Release/System.Private.CoreLib.dll
# 5) bin/Product/Linux.x64.Release/System.Private.CoreLib.ni.dll

CLI team at some point announced the nightly builds, but apparently that plan is not on board any more…

Having the same issue on Fedora 24 after fixing the libicu version issues. Is there a workaround for this?

$ dotnet --version 1.0.0-preview3-003208 $ dotnet new

Decompressing 100% 1951 ms Expanding 4%/usr/local/bin/dotnet: line 5: 11895 Segmentation fault (core dumped) /opt/dotnet/dotnet $ dotnet --info .NET Command Line Tools (1.0.0-preview3-003208)

Product Information: Version: 1.0.0-preview3-003208 Commit SHA-1 hash: 76058bea60

Runtime Environment: OS Name: fedora OS Version: 24 OS Platform: Linux RID: fedora.24-x64

Just to confirm, Debian Stretch does not ship with libssl1.0.0. It was an artifact package required by some userspace apps from the previous release like skype (libssl1.0.0:i386) and rstudio and ruby2.1 (libssl1.0.0:amd64) in my case. I’ve removed both of those packages and now I’m getting this error:

Unhandled Exception: System.TypeInitializationException: The type initializer for 'Crypto' threw an exception. ---> System.TypeInitializationException: The type initializer for 'CryptoInitializer' threw an exception. ---> System.DllNotFoundException: Unable to load DLL 'System.Security.Cryptography.Native.OpenSsl': The specified module could not be found.
 (Exception from HRESULT: 0x8007007E)
   at Interop.CryptoInitializer.EnsureOpenSslInitialized()
   at Interop.CryptoInitializer..cctor()
   --- End of inner exception stack trace ---
   at Interop.Crypto..cctor()
   --- End of inner exception stack trace ---
   at Interop.Crypto.GetRandomBytes(Byte* buf, Int32 num)
   at System.IO.Path.GetCryptoRandomBytesOpenSsl(Byte* bytes, Int32 byteCount)
   at System.IO.Path.GetCryptoRandomBytes(Byte* bytes, Int32 byteCount)
   at System.IO.Path.GetRandomFileName()
   at Microsoft.DotNet.InternalAbstractions.TemporaryDirectory..ctor()
   at Microsoft.Extensions.EnvironmentAbstractions.DirectoryWrapper.CreateTemporaryDirectory()
   at Microsoft.DotNet.Configurer.NuGetPackagesArchiver..ctor()
   at Microsoft.DotNet.Cli.Program.ConfigureDotNetForFirstTimeUse(INuGetCacheSentinel nugetCacheSentinel)
   at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, ITelemetry telemetryClient)
   at Microsoft.DotNet.Cli.Program.Main(String[] args)
Aborted

Is dotnet core v1 supposed to support libssl1.0.2 or do I need libssl1.0.0?

@sekjun9878 - please see this conversation for Debian Stretch: https://github.com/dotnet/core/issues/649#issuecomment-301111400

Fore some reason (probably a system update), now its fine. My bad …

Close the issue then.

@naamunds The former issue manifested in a very random way - the stack segment register was getting overwritten for threads at random times (when GC was starting) and took effect after the GC finished and each thread was resumed and so the issue was always at a different place. I would say that if the issue @Bhaal22 sees has always the same bottom of the call stack, it is a different problem.

As we as a community cannot change the links on http://dot.net to point to a new release

Also would have been nice to have Oracle Linux listed at https://www.microsoft.com/net/download#core by now, which is a supported platform and shares the same package as CentOS (https://github.com/aspnet/EntityFramework/issues/4293#issuecomment-229142303). Can we have a repo where we can send a PR for that website, when the team misses out something? 😃

#LetUsPort.NETCoreToBananaUnixAndGoCrazyWithIt_AKA_Freedom! 🚀 🎸 🎉

@Bhaal22 1.0.0-preview3-003223 is not rel 1.0.0 it has many other new bits in coreclr and corefx , you are running an unstable build which most probably have other issues. This version 1.0.0-preview2-003121 has coreclr and corefx version 1.0.0 , you should be applying the patch to this version.

As this is fixed in dotnet/coreclr#6604 & released with v1.0.4 will we see a preview4 soon of the CLI?

I am not sure of an upcoming CLI preview release but we are trying to determine if we can have a patch update of .NET Core Redist that will carry this change (as it should not require any app update).

@leecow is working on that plan.

@shahid-pk yes, that was the fix.

Can you check all the config that happens in https://github.com/dotnet/cli/blob/rel/1.0.0/scripts/docker/centos/Dockerfile? That sets up our centos docker images for our CI.