dotnet restore fails on Linux 4.6.2

Steps to reproduce

CentOS 7 with kernel-ml installed, the mainline Linux kernel at version 4.6.2.

./dotnet-install.sh -c preview -v 1.0.0-preview2-003121
~/.dotnet/dotnet restore

Expected behavior

Packages to be restored.

Actual behavior

Welcome to .NET Core!
---------------------
Learn more about .NET Core @ https://aka.ms/dotnet-docs. Use dotnet --help to see available commands or go to https://aka.ms/dotnet-cli-docs.
Telemetry
--------------
The .NET Core tools collect usage data in order to improve your experience. The data is anonymous and does not include commandline arguments. The data is collected by Microsoft and shared with the community.
You can opt out of telemetry by setting a DOTNET_CLI_TELEMETRY_OPTOUT environment variable to 1 using your favorite shell.
You can read more about .NET Core tools telemetry @ https://aka.ms/dotnet-cli-telemetry.
Configuring...
-------------------
A command is running to initially populate your local package cache, to improve restore speed and enable offline access. This command will take up to a minute to complete and will only happen once.
Decompressing 100% 2175 ms
Expanding 3%Segmentation fault (core dumped)

Environment data

dotnet --info output:

dotnet --info
.NET Command Line Tools (1.0.0-preview2-003121)

Product Information:
 Version:            1.0.0-preview2-003121
 Commit SHA-1 hash:  1e9d529bc5

Runtime Environment:
 OS Name:     centos
 OS Version:  7
 OS Platform: Linux
 RID:         centos.7-x64

This is a fresh CentOS 7 machine I made to replace the Debian Testing machine I couldn’t build on in dotnet/sdk#6483.

[NinoFloris]

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…

[yetanotherchris]

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