Description of problem: CoreCLR uses mlock during startup and fails if mlock fails with EPERM. Generally, that's not a problem. However, many Linux distributions (including Fedora) are starting to use systemd-nspawn for building code and this creates a chroot where programs have restricted capabilities. Unfortunately, systemd-nspawn in F28 doesn't allow mlock() syscall to be called inside the container. It is possible to change mock config locally: config_opts['nspawn_args'] = ['--capability=CAP_IPC_LOCK'] However, there is no such option in COPR. Version-Release number of selected component (if applicable): current COPR: https://copr.fedorainfracloud.org/ How reproducible: always Steps to Reproduce: 1. Create a very simple RPM package with dotnet 2.1. You can use https://dotnetcli.blob.core.windows.net/dotnet/beta/Binaries/Latest/dotnet-dev-centos-x64.latest.tar.gz (as Source0) or rh-dotnet20-dotnet-host package (as part of BuildRequires). 2. Run this in %prep, %build or %install section: dotnet --version 3. Try build using COPR. Actual results: Failed to initialize CoreCLR, HRESULT: 0x8007001F with strace: mlock(0x7f29b8c7b000, 4096) = -1 EPERM (Operation not permitted) Expected results: 2.1.105 with strace: mlock(0x7fad0f699000, 4096) = 0 Additional info: https://github.com/dotnet/coreclr/issues/18634 https://github.com/rpm-software-management/mock/issues/186#issuecomment-392833446 https://bugzilla.redhat.com/show_bug.cgi?id=1594397#c2
I've deployed a fix for this https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=fac83ee9d9f0b9a800e3a9d54cb53b37f9d197a9. It might take several hours to take effect though. New builder with the modified config need to be spawned first.
Thank you. I can confirm that it works: + ./dotnet --version 2.1.105