`dotnet new command` in openSuse causes `No usable version of the libssl was found` error - linux

I'm trying to develop .NET Core in openSuse. I did install the SDK and everything in tutorials. Now, when I try to run dotnet new console command, I get this error:
No usable version of the libssl was found
Aborted (core dumped)
I found this answer: (.NET Core 2.1 SDK Linux x64 No usable version of the libssl was found), but didn't get what should I do to solve problem. They seems are deep-linuxer (which I'm not, I'm just trying to learn linux). Have any idea how to run the command?
UPDATE: System info:
openSUSE Leap 15.0
Kernel Version 4.12.14-lp150.12.22-default
OS Type:64-bit

I was having the same problem running sqlpackage on Ubuntu 20.04 while dotnet was working regularly.
dotnet is distributed through apt as well as sqlserver, but for some reasons sqlpackage is instead distributed via zip here (https://learn.microsoft.com/en-us/sql/tools/sqlpackage-download?view=sql-server-ver15) and is still affected by missing libssl1.0.
Solved with
wget http://security.ubuntu.com/ubuntu/pool/main/o/openssl1.0/libssl1.0.0_1.0.2n-1ubuntu5.6_amd64.deb
sudo dpkg -i libssl1.0.0_1.0.2n-1ubuntu5.6_amd64.deb

Can you install the libopenssl1_0_0 packages? .NET Core should pick it up and use it.
A slightly longer explanation for anyone who is curious:
OpenSSL is one of the most common cryptographic libraries used on Linux. It has multiple versions. Version 1.0 is kind of old, but heavily used. 1.1 is the newer version that was (relatively) recently released. 1.0 and 1.1 are not compatible. An application that expects 1.0 can not build against 1.1, nor run against it.
.NET Core 2.1, and all earlier versions only support OpenSSL 1.0.
Many Linux distributions are starting to make OpenSSL 1.1 the new default. But most of them still have a package for 1.0. So you just need to find and install that. On Fedora it's compat-openssl10. For openSuSE, it's libopenssl1_0_0. Then .NET Core will find it, pick it up and use it automatically.
Edit: As of March 2019, this shouldn't be required. We have updated .NET Core 2.1 and later to pick up and work with either OpenSSL 1.1 or 1.0 (whatever is available). So this problem should no longer happen with recent releases of .NET Core.

Ubuntu 22.04
wget http://security.ubuntu.com/ubuntu/pool/main/o/openssl1.0/libssl1.0.0_1.0.2n-1ubuntu5_amd64.deb
sudo dpkg -i libssl1.0.0_1.0.2n-1ubuntu5_amd64.deb

Still get this on Fedora 30 (with compat-openssl10 installed) when using the sqlpackage tool (https://learn.microsoft.com/en-us/sql/tools/sqlpackage-download?view=sql-server-2017).
$ dotnet --info
.NET Core SDK (reflecting any global.json):
Version: 2.2.203
Commit: e5bab63eca
Runtime Environment:
OS Name: fedora
OS Version: 30
OS Platform: Linux
RID: linux-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
Dotnet works fine on it's own. But running sqlpackage does not work:
$ sqlpackage /tsn:localhost /tu:xx /tp:yyy /A:Import /tdn:mydb /sf:mydb.bacpac
Importing to database 'mydb' on server 'localhost'.
No usable version of the libssl was found
Aborted (core dumped)

I looking up "No usable version of the libssl was found" in github. You'll find many variants of the .Net core security library in C, each varient has very specific dll loads for exact libssl libraries and everything has to match perfect despite it being named differently in many.
For raspberry pi / debian it wants libssl 1.0.2 exactly, nothing else.
sudo apt-get install libssl1.0.2
should do the trick for the pi! I can't speak to other variants.

Related

"System.PlatformNotSupportedException: Microsoft.Data.SqlClient is not supported on this platform." on Linux

I just started getting this error today on my Linux system, building a net6 solution on Rider - It builds but won't run. I've tried upgrading my version of Microsoft.Data.SqlClient from nuget but that's made no difference. This was working fine last week.
There are a couple of things I've done that may have broken it - I got mono working over the weekend to try and get some legacy NETFramework code building for another project, for one. The other was a global update of ef tools dotnet tool update --global dotnet-ef as I had the 5.x tools version installed.
My OS has multiple runtimes installed...
dotnet --list-runtimes
Microsoft.AspNetCore.App 6.0.0 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.13 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.0 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.13 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.2 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
The app builds to target 6.0.
I'm a bit lost as to where to start trying to find problems - I#ve read about the netstandard2.0 version of this library being a kind of breaking stub, but the Assembly Explorer in Rider tells me that the version of Microsoft.Data.SqlClient in my bin directory is net6. I'm not sure what I should be seeing in the runtimes directory in here - I have a unix runtime shown there but NOT a linux specific runtime - Is this a red herring or am I on to something?
I've reverted the dotnet-ef tool by uninstalling it and running dotnet tool install --global dotnet-ef --version 5.0.0 - This hasn't helped at all.
TLDR: I think this is a bug in the .NET builds of Manjaro Linux. When you downloaded Microsoft's builds of .NET, it didn't have this bug and worked correctly.
This is what the OS says about itself:
# cat /etc/os-release
NAME="Manjaro Linux"
PRETTY_NAME="Manjaro Linux"
ID=manjaro
ID_LIKE=arch
BUILD_ID=rolling
ANSI_COLOR="32;1;24;144;200"
HOME_URL="https://manjaro.org/"
DOCUMENTATION_URL="https://wiki.manjaro.org/"
SUPPORT_URL="https://forum.manjaro.org/"
BUG_REPORT_URL="https://docs.manjaro.org/reporting-bugs/"
PRIVACY_POLICY_URL="https://manjaro.org/privacy-policy/"
LOGO=manjarolinux
And this is what .NET thinks about your OS:
sh-5.1# dotnet --info
.NET SDK (reflecting any global.json):
Version: 6.0.113
Commit: 4a23b50f97
Runtime Environment:
OS Name: manjaro
OS Version:
OS Platform: Linux
RID: arch-x64
Base Path: /usr/share/dotnet/sdk/6.0.113/
...
Do you see how confused .NET is about whether this is Arch Linux or Manjaro?
.NET has a fallback graph that tells it which assets from another OS it can use:
# jq '.runtimes' /usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.13/Microsoft.NETCore.App.deps.json
{
"arch-x64": [
"arch",
"linux-x64",
"linux",
"unix-x64",
"unix",
"any",
"base"
]
}
But that only contains arch-x64 (that is, Arch Linux), not manjaro-x64.
If you try and build/run your application with the environment variable COREHOST_TRACE, you can see output like this:
HostRID is manjaro-x64
Falling back to base HostRID: linux-x64
So it finally decides this OS is Manjaro, but then has no idea that Manjaro is compatible with everything listed in the fallback graph above. It just falls back to Linux.
Unfortunately, Microsoft.Data.SqlClient is built for either Windows (windows) or for Unix (unix). .NET can't find a linux variant. It finally uses the fallback version of Microsoft.Data.SqlClient.dll, one that just prints errors instead of doing anything useful.
It seems that the issue was, in part, related to having 2 6.x framework versions installed, or with 6.0.13 - I'd tried installing the 6.x packages from the Manjaro repositories over the weekend to replace the script installs.
Dani's comment above pointed me in the right direction (https://github.com/dotnet/SqlClient/issues/1643#issuecomment-1265104713) - There's something odd going on here.
I removed them all and installed again using the .dotnet-install.sh script - that just did nothing, so I copied the 6.0.0 install from a backup folder (mv .old FTW) and it all fell into place again.
Whether this is an issue with 6.0.13 or with having multiples I'm not sure.

node-webcrypto-ossl, GLIBC_2.32 not found, Manjaro OS

When I try to run an application that uses node-webcrypto-ossl node module I get the error:
Error: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found.
Obviously node-webcrypto-ossl requires an older version of glibc.
The version of glibc installed on my machine is 2.33-5. I've tried downgrading my glibc but ended up with a broken system (fixed it already).
How do I resolve the issue?
Obviously node-webcrypto-ossl requires an older version of glibc.
No. GLIBC is backwards compatible: applications built against older version continue to run fine on newer GLIBC versions.
Your problem is the opposite: you have an application linked against GLIBC_2.32 trying to run against an older version of GLIBC.
The version of glibc installed on my machine is 2.33-5
The application is not using that version; it's using some other GLIBC.
The problem was that I was trying to run my app in docker ...
That's one way running against older than expected GLIBC could happen.

version `GLIBC_2.33' not found

I'm using .net core on Linux specifically Manjaro 20.2.1, I'm learning .net core, I want to use EF commands, but it's slightly different how its works on Linux, I had installed the dotnet-ef tool whit this command:
dotnet tool install --global dotnet-ef --version 5.0.3
So when I try to run donet ef throws me this error:
/home/$USERNAME/.dotnet/tools/dotnet-ef: /snap/core18/current/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /usr/lib/libstdc++.so.6)
But it seems that the GLIBC version that it's installed on my distro is: 2.33-3, and its seems that the version that it's looking for it's specifically the 2.33.
How I can get rid of this problem?
It seems that something in dotnet depends on GLIBC 2.33 but dotnet is tied to core18 which is using GLIBC 2.27.
λ snap list
Name Version Rev Tracking Publisher Notes
core 16-2.48.2.1 10823 latest/stable canonical✓ core
core18 20210128 1988 latest/stable canonical✓ base
dotnet-sdk 5.0.103 112 latest/stable dotnetcore✓ classic
λ file /snap/core18/current/lib/x86_64-linux-gnu/libc.so.6
/snap/core18/current/lib/x86_64-linux-gnu/libc.so.6: symbolic link to libc-2.27.so

asp.net core 2.1 on arch linux does not run

I have installed the latest version of the .net core using pacman on an Arch Linux:
sudo pacman -S dotnet-sdk
Running dotnet --info shows the correct version:
Host (useful for support):
Version: 2.1.0
Commit: caa7b7e2ba
.NET Core SDKs installed:
2.1.0 [/opt/dotnet/sdk]
2.1.300 [/opt/dotnet/sdk]
I can run console applications, but when I run dotnet run in an ASP.NET Core directory return this error:
It was not possible to find any compatible framework version The
specified framework 'Microsoft.AspNetCore.App', version '2.1.0' was
not found.
Why though versions seem to match, it doesn't run?
More details:
ls /opt/dotnet/sdk/ returns:
2.1.300 NuGetFallbackFolder
Contents of the .csproj file:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.1</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>
</Project>
This question is old, but in case someone's trying to get .NET 5 to run on Arch, this can give you another solution.
If you build, publish and run the project specifying the platform runtime, dotnet will build a self-contained application, with all necessary platform specific dependencies.
You can do that with the --runtime/-r flag.
Examples for Arch:
dotnet build -r linux-x64
dotnet run -r linux-x64
dotnet publish -r linux-x64
Refer to Microsoft docs for the available runtime identifiers:
https://learn.microsoft.com/en-us/dotnet/core/rid-catalog
Edit:
I've also had less problems with paths using the AUR package instead of Snap's:
https://aur.archlinux.org/packages/dotnet-sdk-bin/
Edit 2:
After installing AUR's aspnet-runtime-bin package, all errors about Microsoft.AspNetCore.App not being found disappeared, without using the --runtime flag:
https://aur.archlinux.org/packages/aspnet-runtime-bin
.NET Core is not currently supported on Arch, so there's no guarantees that it will work at all. Currently the following distros are supported on 64-bit:
Red Hat Enterprise Linux 7, 6
CentOS 7
Oracle Linux 7
Fedora 27
Debian 9, 8.7 or later versions
Ubuntu 18.04, 17.10, 16.04, 14.04
Linux Mint 18, 17
openSUSE 42.3 or later versions
SUSE Enterprise Linux (SLES) 12 Service Pack 2 or later
Alpine Linux 3.7 or later versions
See this page for more info.
You can see these issues related to Arch in the dotnet repos:
https://github.com/dotnet/coreclr/issues/4409
https://github.com/dotnet/corefx/issues/19447
https://github.com/dotnet/core-setup/issues/3845
I don't have a proper solution for your problem but maybe a workaround. I am using elementary os and .net core 2.1 works just fine, but I noticed that my path to the metapackages is different from yours:
.NET Core SDK (reflecting any global.json):
Version: 2.1.300
Commit: adab45bf0c
Runtime Environment:
OS Name: elementary
OS Version: 0.4.1
OS Platform: Linux
RID: linux-x64
Base Path: /usr/share/dotnet/sdk/2.1.300/
Host (useful for support):
Version: 2.1.0
Commit: caa7b7e2ba
.NET Core SDKs installed:
2.0.0 [/usr/share/dotnet/sdk]
2.1.300 [/usr/share/dotnet/sdk]
You could try to copy the metapackages from your installation folder /opt/dotnet/shared to /usr/share/dotnet/shared
This guy over here has a similar problem using Fedora: https://github.com/dotnet/core-setup/issues/4022
#tura08 answer is wrong, because .NET Core should work on Arch Linux like on every other Linux system.
I was experiencing same issue so I just reported it https://github.com/dotnet/core-setup/issues/4216 and it seems dotnet-sdk package is missing aspnetcore-runtime-2.1 dependency. I wrote email to maintainer, so I hope he will fix package soon.
I had a similar issue trying to get global tools installed. Creating a symlink worked for me:
ln -s /opt/dotnet/ /usr/share/dotnet
Upgrading all the packages solved the problem:
pacman -Syu
It includes the dotnet-sdk package 2.1.300-2 updated on 2018-06-12 11:24 UTC:
https://www.archlinux.org/packages/community/any/dotnet-sdk/

How to upgrade Qt installed in linux from one version to higher

While porting Qt project from windows to linux(ubuntu) i faced with the following issue:
on windows Qt version 4.8.1 is installed
on linux 4.6.3 in which some functionalities availiable in higer version 4.8.1 don`t yet implemented (ex. QUdpSocket::joinMultiCastGroup).
I see only one solution to this problem: upgrade Qt version on linux to 4.8.1.
How can I do this?
On linux I got installed libqt4-dev, qmake.
Solved: I changed repository from squeeze (stable) to wheezy(testing), in wheezy latest Qt version is 4.8.1, which is perfectly suits my needs.
Using package manager I found package libqt4-dev and selected it for update.
That is all, the whole process took 5 minutes.
Disadvantages:
- As I run Debian on Virtual Box after changing repository I had to reinstall guest additions
- wheezy is less stable than squeeze (I haven`t faced yet with stablilty problem)
I guess you can use Upgrade option in the Qt Creator.
Or you can download latest version from Download Qt, the cross-platform application framework
Or you could try to update using something like apt-get install(upgrade) libqt4-dev if you using Debian based system.
This depends on the distro you are using. If there are binary packages for your distro you can update through your package manager. Otherwise you have to download the source of your prefered Qt version and build it yourself.
I'm not sure if this will help in your situation, but you can download the Qt Online Installer at the following link:
https://www.qt.io/download-qt-installer

Resources