Create a sane pre-built binary for Linux systems about xmr-stak HOT 40 CLOSED

from xmr-stak.

from xmr-stak.

@psychocrypt If you can't have a single binary with built in libc in docker then let's ditch it and work with a system that enables it (Applmage).

Here are the requirements as I see it:

• Single binary for all common linux systems.
• Independent of native libc build
• Independent of native openssl
• Includes libhwloc and libmicrohttpd in the package

from xmr-stak.

from xmr-stak.

I don't want to have 5 separate binaries ( minimum pointful support would be: Fedora, Debian, Ubuntu, Arch and CentOS ). Hence the Single binary for all common linux systems requirement.

I'm open to any packaging systems that meets all of the above.

from xmr-stak.

from xmr-stak.

Thanks, most likely you will need to package a lot of cuda and opencl libraries, but I don't really see a problem with that. We can have a CPU-only "light" version for people that don't want to download a huge (likely in 10's of MB package)

from xmr-stak.

from xmr-stak.

As long as all the requirements are met - I don't mind. But keep in mind that requirements are single and binary I want to capture users that don't really have a lot of experience building software and people looking to deploy a single image on mining vms.

from xmr-stak.

@fireice-uk

I created a appImage version of the current dev for debian and ubuntu 14.04+
https://mega.nz/#!BHxRWYhB!RyRK-mW4NmCH2BEs1vT6CObWsx7AtLgCyQwiPOS1WGo
SHA256: 1b3aff890f1e8f0d5fb554b26db7360f7e127bddb18b17f29c3382d801b9f861

Double klicking on the binary is currently not working but usage on the terminal should work. If you have also other linux distribution it would be interesting if it is working too.

from xmr-stak.

@psychocrypt I had a look myself and I shifted the goalposts a little.

• Fuse is a pain in the arse to get running on VMs where you don't control the kernel
• binary + libraries + start script seems to work well (tested ubuntu 16.04-built binary with TLS on centos 6)

Here is my rough first attempt - just unpack, and run xmr-stak.sh

https://transfer.sh/Jo1fY/stak-portable.tar.gz

from xmr-stak.

from xmr-stak.

So you tried my appImage build? This was compiled on a ubuntu 14.04 and ships all importent libraries.

I tried and it works fine for me on Ubuntu 17.10.

from xmr-stak.

@psychocrypt I tried but my VM provided does not have FUSE in the kernel, so no joy for any OS.

I prefer to drop the single binary requirement and use the more compatible script launch method.

from xmr-stak.

You can extract an AppImage like so, even on systems without FUSE installed:

./xmr-stak --appimage-extract

This is also documented on https://github.com/AppImage/AppImageKit/wiki/FUSE

from xmr-stak.

I know, but then I got a segfault until I added a script to launch the binary myself. Given that we are aiming for something that can be deployed via scripts here and not a pretty binary I don't see any advantage to having it in appimage over tarball.

from xmr-stak.

Maybe because I rolled the image on Ubutu 16.04 and tested it on CentOS 6 and not the other way round -> but that just shows that tarball is the more compatible solution imo.

from xmr-stak.

This is entirely independent of whether you wrap your binaries in an AppImage, a tarball or something else: They will run on newer, but not on older systems than the one they were compiled on. Unless you bundle everything, down to glibc.

from xmr-stak.

@probonopd Thanks for great software BTW, I develop stak from KDevelop bundled in appimage!

Idea is to bundle everything down to libc - will appimage work in that case? I can give it another shot.

from xmr-stak.

@fireice-uk again: if you have a tarball that is working "everywhere", then simply put the contents of said tarball into the AppImage. AppImage has nothing to do with whether your binaries are compatible or not. AppImage is just a self-mounting filesystem that runs whatever you put inside it.

And yes, when you bundle everything down to glibc, then it will run everywhere indeed. Here's a hint at how to do it:

https://gist.github.com/probonopd/fab5d43c1e54f528b22c7398817b67b0

But you'd probably need the 64-bit glibc instead.

from xmr-stak.

@probonopd thanks for the hint -> I was using your binary AppRun. Will test it with the launcher script as the AppRun.

from xmr-stak.

@fireice-uk You provided binary runs well on Ubuntu 14.04 expect if I use the nvidia miner. I get the following error message:

[2017-11-18 20:58:59] : Difficulty changed. Now: 18000.
[2017-11-18 20:58:59] : Pool logged in.
Invalid NH nonce on CPU SINGLE - 0x0000600a

But this is currently not merged into the dev.

Btw: To path all parameter from the script to the xmr-stak binary I use always $@ instead of $* but maybe it must be `"$@"
see https://unix.stackexchange.com/a/129077

from xmr-stak.

@psychocrypt It works! Do you think we should do a last minute change or ship a tarball now and listen to feedback from the miners?

from xmr-stak.

@psychocrypt you are using the test-dev-fireice-nh branch -> this branch is for testing NH nonces, you need to enable nh nonces for it to work. It isn't meant to be merged.

from xmr-stak.

@fireice-uk Do you mean shipping a appImage instead of a tar ball?

from xmr-stak.

@psychocrypt Yes, my feeling would be not to make a major change right now -> we only have this evening to test it. We can do a follow up release in a week or a fortnight.

from xmr-stak.

from xmr-stak.

@fireice-uk Double klicking on the sh file and select run in linux will start the miner in the background and if a config already exists the power consumption of the system goes up without a running miner.
For appImage I tried to find a valid terminal on the system and start it if the user double klick the miner and there is no open termin.
This can avoid a lot of potential issues. I used the following code but it was not running well, this means we need to fix it.

if [ -z $VTE_VERSION ] ; then
    for i in  x-terminal-emulator xterm  
    do 
        which $i
        if [ $? -eq 0 ] ; then
           # -e is not the correct option for all terminal emulators
            "$i" -e "xmr-stak $@"
            break
        fi
    done
else
    xmr-stak $@
fi

update The process is running in the background but due to the missing terminal the user will not see it and non expert user will have issues to kill the process.

from xmr-stak.

@psychocrypt yes, it isn't the release version yet :) just checking whether it starts

On point of cuda8. I just verified that you don't need new drivers for a cuda9 binary. As such I will build it on 9.0 <- i really don't feel like tearing down and rebuilding vs toolchain.

Can you make cuda8 legacy binaries? We will keep them until they fall below 1% of usage.

With regards to Linux GUI terminals... This is something for after the release - right now the primary focus is to have an easy-to-deploy binary for people that mine on VMs.

from xmr-stak.

There is no need to ship two binaries if it is compiled with CUDA8. Please do not open a new potential source of issues because the user is always downloading the wrong binary :-) Also the most user don't know if the have a fermi GPU or not. You can check the issues in xmr-stak-nvidia wheremany user compile for the wrong architecture.
We have now the possibility to ship a single miner for all important platforms but by skipping fermi support we will not reach it.
You can install the CUDA 8 toolkit into the user home and use it to build the binaries (there is no driver required)
Cuda9 binaries will not be guarantied compatible with CUDA8. I am currently searching for the source within the programming guide and will post it soon.

from xmr-stak.

The compatibility link: http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#versioning-and-compatibility

from xmr-stak.

@psychocrypt They are. I just tested that. We will roll with two binaries for now to asses the need for cuda8.

from xmr-stak.

But why? We have only disadvantages with CUDA9.

• no single binary fits all
• it is more complicated for the user
• we need to build two binaries

Which argument is pro CUDA9?

from xmr-stak.

• We get to use VS17, no need to downgrade toolchains
• I have an inkling that number of users affected will be well below 1% in which case we will drop cuda8 altogether. There is no point in maintaining binary for edge cases.

from xmr-stak.

Than we should only ship one binary without fermi and with the potential risk if CUDA8 driver incompatibilities.
My vision is and was to create a simple miner (from the user perspective) where we avoid as much as possible issues by design. This will be not the case with the next release and this makes me sad :'(

I go to bed now, with a bad feeling.

I have an inkling that number of users affected will be well below 1% in which case we will drop cuda8 altogether. There is no point in maintaining binary for edge cases.

With this release we will get also new users from the Aeon community where older gpus are still profitable.

from xmr-stak.

As I said - we will reassess when we have the actual numbers. Don't get so emotional :P if there are issues I will pull c9 build and we will have a c8 only build

from xmr-stak.

The point is there is no need to skip fermi support in the near feature. I can extent the plugin system that we ship a library only for sm_20 which must compiled with CUDA8 and the rest can be compiled with CUDA9. But this is nothing for this release because this must be implemented and tested.

from xmr-stak.

we should add the guard to avoid spawning dead background miner.

if [ -z $VTE_VERSION ] ; then
    echo "xmr-stak is not started from a terminal session, aborted." >2
else
    $SCRIPT_PATH/stak/ld-*.so.2 --library-path $SCRIPT_PATH/stak $SCRIPT_PATH/stak/xmr-stak $@
fi

from xmr-stak.

Did you end up deciding on a portable / one click method for linux? It's mentioned here but I don't see any such files on the Releases page.

from xmr-stak.

@sifotes we had it for a short time but it wasn't portable enough so we pulled it. It is still in the works, so check back later.

from xmr-stak.