Fedora RPM

[gtirloni]

Please provide RPMs for Fedora too.

The CentOS RPM isn't a workaround because it doesn't work on Fedora 24 at this moment:

$ powershell 
Failed to initialize CoreCLR, HRESULT: 0x80131500

[andyleejordan]

Ah yes, we'll need to start building for fedora.23-x64 .NET Core RID too. It will come! (If you want to do it, it's just a few additions of that RID to the correct project.json files and a couple places in build.psm1, and then generate a new package with New-UnixPackage.) I would love to accept a PR like that!

[JoaaoVerona]

Pretty please!

[mattico]

@gtirloni this hn comment explains a method to get it working on Fedora 24.

But yes, a native package would be nice.

[ImNtReal]

Any chance the .spec file used to build the current RPM could be released to make it easier to figure out how to package for other distros?

[gromnitsky]

@ImNtReal judging from build.psm1 they are not writing .spec file directly but are using https://github.com/jordansissel/fpm for the rpm generation.

[eliasward]

As a temp workaround, I was able to get it running using https://nmilosev.svbtle.com/running-net-core-rc2-on-fedora-23

[brandon-arnold]

In the meantime for Fedora 24, install the older LibICU package from ftp://195.220.108.108/linux/fedora/linux/releases/23/Everything/x86_64/os/Packages/l/libicu-54.1-5.fc23.x86_64.rpm as per this dotnet issue.

[plinnell]

Using fpm for rpm and .deb generation is sub optimal. Source rpms and .deb files are desirable for a repeatable build outside someone's random build environment. This will be important for acceptance in enterprise distros as well as Debian.

I strongly recommend looking at https://openbuildservice.org for Linux builds as it not only covers a wide range of popular distros, but easily supports building on non X86 arches, everything from tiny Arm5 to IBM mainframes. OBS as we call it is 10+ years of maturity and the most powerful build platform for native Linux packages.

If the build team is in Redmon, I'll gladly drop in and show them how it works. It also integrates with Jenkins/Git workflows for CI.

[andyleejordan]

Using fpm for rpm and .deb generation is sub optimal.

Totally agree, but it was very quick to go from zero to multiple packages 😉

I'm unclear if we should own the creation of packages for distributions to release. My understanding is that usually outside package maintainers pick up your build output and source, and create packages for their distribution; not pickup packages from you. However, I don't know if this is the route they'll take with PowerShell. If distributions end up wanting us to maintain the actual packages going into their repositories, we absolutely will need to create them from scratch (RPM spec etc.).

[gtirloni]

It would be ideal to have packages accepted into the official repositories but that usually requires quite some time from maintainers. I think it's unreasonable to request this from open source projects.

If there are volunteers or a company with a vested interest in having these packages, then I'm sure we'll see that in time.

It's completely acceptable for the upstream project to only provide packages generated through fpm. It's already much better than just releasing the source code or some zipped binaries.

As for this specific issue, rebuilding on Fedora 24 with the correct requirements properly defined and a new RPM being made available through the website is all that's needed, in my opinion.

[xasx]

Maybe people from RedHat get interested in or can be convinced to getting respective packages sooner into their upstream Linux ⁉️

[jrm16020]

CentOS provides a Docker container with Powershell installed. Why not just use it and a shell function to start it? Maybe something like this?

powershell () {
    DOCKER_RUN="docker run --rm --name powershell -it"
    DOCKER_IMAGE="centos/powershell"
    DOCKER_COMMAND="/usr/bin/powershell"

    ## Check permissions on Docker socket and fix if necessary
    if [[ ! -w /var/run/docker.sock ]]; then
        sudo setfacl -m u:$( whoami ):rw /var/run/docker.sock
    fi

    ## Make sure Powershell image is installed
    if [[ "$( docker images | grep -i powershell &>/dev/null; echo $? )" != "0" ]]; then
        printf "Pulling powershell image for use...\n"
        docker pull "${DOCKER_IMAGE}" &>/dev/null
    fi

    ## If we passed arguments, parse them, and if necessary, mount in the directory of the script we're trying to execute.
    if [[ "$#" > 0 ]]; then
        ARGS="$@"
        while [[ "$#" > 0 ]]; do
            if [[ "$1" == *".ps1"* ]]; then
                CURRENT_DIR=$( dirname $1 )
            fi
            shift
        done

        if [[ -n "${CURRENT_DIR}" ]]; then
            ${DOCKER_RUN} -v ${CURRENT_DIR}:/opt/powershell_volume:rw -w /opt/powershell_volume ${DOCKER_IMAGE} ${DOCKER_COMMAND} ${ARGS}
        else
            ${DOCKER_RUN} ${DOCKER_IMAGE} ${DOCKER_COMMAND} ${ARGS}
        fi
    else
        ${DOCKER_RUN} ${DOCKER_IMAGE} ${DOCKER_COMMAND}
    fi
}

[suvayu]

@jrm16020, doesn't that defeat the purpose a bit? It's a shell after all; I would like to try powershell as a regular shell for a few days side-by-side with my usual shell. Wouldn't that be impossible when using a docker container?

[xasx]

Wouldn't that be impossible when using a docker container?

Running apps directly from a docker container is not that unusual these days. A lot of convenience has been added around launching applications this way.
However, for a shell, I admit that a lot more of the mentioned convenience would have to be added.

I guess that's what @jrm16020's script tries to achieve.

Mounting the current directory into the container might not be enough. Actually, I guess that everything that is accessible (file system, internet, registry etc.) through powershell would have to be mounted into the container so that it feels like working natively.

All that said, it's probably not impossible but a lot of work is to be done, bringing all into the container. I bet it is easier to build native executables that work directly on your 'disclosed' OS.

[jrm16020]

Wouldn't that be impossible when using a docker container?
... but a lot of work is to be done, bringing all into the container.

No, not really. The example that I posted above works for my use case but it's not a big deal to modify it to serve your purposes. In your case you'd run a privileged container and mount all of your local filesystem into the container. Your container will already have the networking capabilities that your bash/zsh/dash shell has since it's a privileged container and has access to any of the binaries of your Linux host.

docker run --rm --name powershell --privileged -v /:/system -it centos/powershell /usr/bin/powershell

docker run --rm --name powershell --privileged -v /:/system -it centos/powershell /usr/bin/powershell
PowerShell 
Copyright (C) 2016 Microsoft Corporation. All rights reserved.

PS /> ping 8.8.8.8                                                                                                                                                                                    
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=45 time=40.1 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=45 time=25.0 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=45 time=23.5 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 23.536/29.576/40.173/7.517 ms
PS /> 

I don't mean to discount the request for native Fedora packages. I'm a Fedora user and would enjoy seeing a native package as well. That said, there are ways to get Powershell working on your system as it's currently built without depending on an RPM. Docker is the perfect way to package software for easy consumption by all Linux distributions.

[signum187]

Maybe this workaround could help. (source: https://news.ycombinator.com/item?id=12314693)

"henry_flower 19 days ago | parent | favorite | on: PowerShell is open sourced and is available on Lin...

For Fedora 24 users:

So some reason, the rpm that Microsoft provides doesn't list all the dependencies that it actually requires. What is even worse, the compiled binaries inside, require quite outdated versions of icu & openssl that are not available in Fedora 24 any more.

What I've come up w/ to force poweshell to run:

dnf install icu lldb lldb-devel lttng-tools lttng-ust

To view what we're still missing:

$ find /opt/microsoft/powershell -name *.so -type f | xargs ldd 2>/dev/null | grep not\ found
libcrypto.so.1.0.0 => not found
libicuuc.so.50 => not found
libicui18n.so.50 => not found

(libcypto* is openssl-libs package, libicu* is libicu.)

Now, you need to manually download:

http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/17/Everything/x86_64/os/Packages/o/openssl-1.0.0i-1.fc17.x86_64.rpm

(Yes, it's Fedora 17 == 2012 (!), which is ridiculous.)

http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/19/Everything/x86_64/os/Packages/l/libicu-50.1.2-5.fc19.x86_64.rpm

and extract usr/lib64/* files from both rpms to, say, /opt/tmp/lib64.

Then finally run:

$ LD_LIBRARY_PATH=/opt/tmp/lib64 powershell
PowerShell
Copyright (C) 2016 Microsoft Corporation. All rights reserved.

PS /home/hf> $PSVersionTable

Name Value

---

PSVersion 6.0.0-alpha
PSEdition Core
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 3.0.0.0
GitCommitId v6.0.0-alpha.9
CLRVersion
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

It's a very strange feeling to see "Copyright (C) 2016 Microsoft Corporation" in xterm, if you ask me."

[MaximoTrinidad]

Awesome! I able to install PowerShell 6.0 on Fedora 24 Desktop OS.

The instructions in the link provided by Imward works: https://nmilosev.svbtle.com/running-net-core-rc2-on-fedora-23

Woohoo!

[andyleejordan]

For anyone who wants to get started on this, the minimum requirements would include:

To get it working:

• Add Fedora Runtime Identifiers to all relevant project.json runtimes sections
• Ensure all Pester tests pass on a base install of Fedora

To get it published:

• Update New-UnixPackage to generate a Fedora package
• Update download.sh to install the package (there's a race condition here because we download packages from GitHub... but until it's made and published that can't be done)
• Create a pair of Dockerfiles to build PowerShell on an Fedora container (same race condition)
• Update Linux installation docs

The PowerShell maintainers are adding this to GitHub and Digital Ocean's Hacktoberfest for anyone wanting to participate.

.NET Core supports Fedora 23.

[rramoscabral]

The download.sh say 'Fedora is not supported!' , using Fedora 23 (4.7.10-100.fc23.x86_64).
I have .net core 1.0.0-preview2-003131 (https://www.microsoft.com/net/core#fedora).

When trie to run PowerShell 'Failed to initialize CoreCLR, HRESULT: 0x80131500'.

I didn't do the downgrade libicu to libicu-50.1.2-15.el7.x86_64.rpm

[jwflory]

Would definitely love to see this supported on current versions of Fedora!

[anthonykirby]

Another Fedora (24) user here: Following the above suggestions, I felt uncomfortable about using old versions of openssl! I found that Mageia Cauldron packages a more recent libssl.so.1.0.0 (1.0.2j at time of writing), and using this satisfied my conflicting "get it working" and "be safe" requirement.

So I'd suggest taking whatever lib64openssl1.0.0-xxxxxxx.mga6.x86_64.rpm is provided in http://mirrorservice.org/sites/mageia.org/pub/mageia/distrib/cauldron/x86_64/media/core/release/ & using that instead of the 1.0.0i from Fedora 17.

[AndrewSav]

@mirichmo So this fix was reverted #2970 Should this issue be re-opened?

[andyleejordan]

@AndrewSav I brought the changes back in #2982; however, the work done so far enables the RPMs to be built, but does not make them part of the build process. I have #3026 open for updating the documentation and adding Fedora RPMs to the releases. I'll reopen this until the issue is completed.

[cyplo]

I think there is a copr repo managed by @nmilosev for dotnet CLI (https://github.com/dotnet/cli/issues/4866) already, it addresses this specific libicu problem on Fedora, would it be possible to reuse some of their infrastructure here ?

[AndrewSav]

@cyplo, I'm sorry if this is completely off the mark, but the copr repo simply downgrades libicu If I understand it correctly. I understand this is undesirable as a permanent solution, since something else might require the latest version of libicu.

[nmilosev]

Hi,

this package avoids the libicu issue by rebuilding core components of the framework (CoreFX, CoreCLR, libuv, core-setup). We are also using SDK built for RHEL by a RHEL developer Omair. We had to go this way, instead of bundling libicu because Fedora's policies forbid bundled libraries. (https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries)

There was a pull request in one of the repos which fixes the libicu issue. If you download 2.0 nightly builds, libicu issue is non present. Sadly it didn't make it in 1.1.1 release.

All the code for Fedora's package is hosted here on F25 branch: http://pagure.io/fedora-dotnet

Pinging @omajid @tmds @RheaAyase

[RheaAyase]

Please refer to https://fedoraproject.org/wiki/DotNet for Fedora .NET Core packages, always up-to-date reference to whatever you're looking for.

[DarkLite1]

After ending up on this post, I finally installed PowerShell on Fedora 25 as following:

As explained here, fist install the Fedora .NET Core package:

sudo dnf config-manager --add-repo https://copr.fedorainfracloud.org/coprs/nmilosev/dotnet-sig/repo/fedora-25/nmilosev-dotnet-sig-fedora-25.repo
sudo dnf update
sudo dnf install dotnetcore

Then download the RPM for CentOS 7 and install it.
sudo dnf install Downloads/powershell-6.0.0_beta.1-1.el7.centos.x86_64.rpm

You are now able to execute the statement below to open the PowerShell prompt:
powershell

[RheaAyase]

For future readers - Please always refer to the source about installing anything, do not use copypasta cut out of other places, because it will not be updated and maintained here. Look up these instructions on Fedora .NET wiki (which will refer you to the right download instructions for your version)

[DarkLite1]

You are correct, comment updated.

[rjmholt]

What's the status of this issue? I believe our RPM release is working with Fedora 27?

[RheaAyase]

What's the status of this issue? I believe our RPM release is working with Fedora 27?

That's not how packaging works in Linux.

Open Source products are built and packaged by package maintainers, not by the authors of the products. Yes, one may be both, but in the case of .NET Core that is in no way true. Package maintainers can make sure that said product works with all the quirks of their Linux distribution, and they have to comply with it's rules. Among the many rules of Fedora packages, one of the main ones is that the packages have to be fully built from source, including the tools used to do so. All done in Fedora, for Fedora. This way we can make sure that there is nothing spooky coming from some 3rd party binary that could cause issues or vulnerabilities, etc...

.NET Core is packaged by the Fedora .NET SIG and all the information around .NET Core in Fedora is maintained and always up to date at fedoraloves.net

On a side note, as you can also find out on our pages, .NET Core, VSCode and other packages published by Microsoft are not free software, are under proprietary licenses, and contain proprietary code and libraries. We exclude these bits and pieces from our packages and provide necessary hacks to get the sh!# to work.

---

Now on topic of PowerShell packages themselves, I've not looked into it so I can not tell if it's the same as the above and with the same issues. From a glance from afar, those are not Fedora packages. They're rhel packages. There is major difference, so I expect a huge load of issues.

(I'll take a closer look some time next week.)

[RokeJulianLockhart]

https://docs.microsoft.com/en-us/powershell/scripting/install/install-fedora?view=powershell-7.2#installation-via-package-repository successfully installs PowerShell for me. Consequently, does this issue exist to ensure that the package is added to Fedora's default repository?

[RokeJulianLockhart]

#1882 (comment)

Official support for Fedora appears to have been revoked, which explains why the hyperlink (https://docs.microsoft.com/en-us/powershell/scripting/install/install-fedora?view=powershell-7.2#installation-via-package-repository) that I previously provided (at #1882 (comment)) is inoperative. Does that invalidate this issue? I hope not: the RPM is perfectly operative for me, so this decision appears to be unreasonable.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[RokeJulianLockhart]

#1882 (comment)

@jw, I mean that https://docs.microsoft.com/en-us/powershell/scripting/install/install-fedora was replaced by solely https://learn.microsoft.com/en-us/powershell/scripting/install/install-rhel?view=powershell-7.4. RHEL isn't Fedora, even if their .RPMs are occasionally adequately compatible to use.

404 - Content Not Found

Installing PowerShell on Red Hat Enterprise Linux (RHEL) - PowerShell

Information about installing PowerShell on Red Hat Enterprise Linux (RHEL)

[microsoft-github-policy-service]

This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.