>> (p.1)
    Author Topic: CentOS 5.5 Mining Guide for ATI/poclbm  (Read 19526 times)

    • stickman (OP)
    Newbie
    *
    Offline Offline

    Activity: 18
    Merit: 0


    View Profile
    May 08, 2011, 02:34:29 AM
    Last edit: May 08, 2011, 08:10:23 AM by stickman
     #1
    So I've had a text file I've been using when setting up new miners under CentOS 5.5, and I figured I'd share it with the community.  Everyone seems to be using Ubuntu, which is great, but I've only run into problems when trying to get everything configured in Ubuntu.  For me, CentOS has been much easier than Ubuntu, so here goes:

    First off, when I install CentOS I choose only the Server GUI package group which I then customize by clicking the Customize Now radio button.  I then deselect everything under the Servers group, and make sure I select Development Libraries and Development Tools (or something like that).  This guide starts off after logging into the system after a fresh install.

    Install ATI Drivers:
    wget http://www2.ati.com/drivers/linux/ati-driver-installer-11-4-x86.x86_64.run
    sh ati-driver-installer-11-4-x86.x86_64.run
    <go through the install process>
    aticonfig --adapter=all --initial --force


    Install and configure AMD APP SDK
    wget http://download2-developer.amd.com/amd/APPSDK/AMD-APP-SDK-v2.4-lnx64.tgz
    tar -xf AMD-APP-SDK-v2.4-lnx64.tgz
    cd AMD-APP-SDK-v2.4-lnx64
    cp lib/x86_64/*lib64/
    cp icd-registration.tgz
    cd
    tar -xf icd-registration.tgz
    rm -f icd-registration.tgz
    cd ~
    echo AMDAPPSDKROOT=/root/AMD-APP-SDK-v2.4-lnx64 >> .bashrc
    echo AMDAPPSDKSAMPLESROOT=/root/AMD-APP-SDK-v2.4-lnx64 >> .bashrc
    echo LD_LIBRARY_PATH=/root/AMD-APP-SDK-v2.4-lnx64/lib/x86_64 >> .bashrc

    Install Python 2.7
    wget http://www.python.org/ftp/python/2.7.1/Python-2.7.1.tgz
    tar -xf Python-2.7.1.tgz
    cd Python-2.7.1
    ./configure
    make && make install
    cd ~

    Install NumPy
    wget http://downloads.sourceforge.net/project/numpy/NumPy/1.6.0b1/numpy-1.6.0b1.tar.gz
    tar -xf numpy-1.6.0b1.tar.gz
    cd numpy-1.6.0b1
    python setup.py install
    cd ~

    Install PyOpenCL
    wget http://pypi.python.org/packages/source/p/pyopencl/pyopencl-2011.1beta3.tar.gz
    tar -xf pyopencl-2011.1beta3.tar.gz
    cd pyopencl-2011.1beta3/
    python configure.py \
      --cl-inc-dir=/root/AMD-APP-SDK-v2.4-lnx64/include \
      --cl-lib-dir=/root/AMD-APP-SDK-v2.4-lnx64/lib/x86_64 \
      --cl-libname=OpenCL
    python setup.py install
    cd ~

    Install JSON-RPC
    svn co http://svn.json-rpc.org/trunk/python-jsonrpc
    cd python-jsonrpc/
    python setup.py install
    cd ~

    Install Git
    wget http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm
    rpm -i epel-release-5-4.noarch.rpm
    yum install git -y

    Clone latest poclbm
    git clone git://github.com/m0mchil/poclbm.git
    -or-
    git clone https://github.com/m0mchil/poclbm.git

    REBOOT
    reboot

    TA DA!  After you reboot, you should be able to run poclbm and start mining!  Please let me know if there's anything I can change here to improve this guide, or if anyone has any problems when using this.  Using this method I'm currently able to mine at 375 Mh/s on a 5870 clocked @ 900 MHz.

  • error
    Hero Member
    *****
    Offline Offline

    Activity: 588
    Merit: 500



    View Profile
    May 08, 2011, 03:17:47 AM
     #2
    I find it's better to git clone the miner, as it makes it much easier to update later.
    3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8

  • stickman (OP)
    Newbie
    *
    Offline Offline

    Activity: 18
    Merit: 0


    View Profile
    May 08, 2011, 07:33:24 AM
     #3
    Quote from: error on May 08, 2011, 03:17:47 AM
    I find it's better to git clone the miner, as it makes it much easier to update later.

    That's a great point, I just made the update.  It also prevents problems if m0mchil adds any additional files because I remember doing it the way I had been (until you showed me the light) when he added sha256.py and I couldn't figure out why things weren't working.  This would have saved me some frustration Wink

  • bitcoindaddy
    Hero Member
    *****
    Offline Offline

    Activity: 481
    Merit: 500


    View Profile
    May 09, 2011, 03:24:30 PM
     #4
    I tried your instructions on CentOS 5.6 and so far so good, but when I download and try to run Bitcoin, it gives me this message:

    ./bitcoin: error while loading shared libraries: libgio-2.0.so.0: cannot open shared object file: No such file or directory

    I like to run bitcoin on the machine doing the mining and I don't use a pool.  Any ideas?

  • stickman (OP)
    Newbie
    *
    Offline Offline

    Activity: 18
    Merit: 0


    View Profile
    May 09, 2011, 03:32:26 PM
     #5
    Quote from: bitcoindaddy on May 09, 2011, 03:24:30 PM
    I tried your instructions on CentOS 5.6 and so far so good, but when I download and try to run Bitcoin, it gives me this message:

    ./bitcoin: error while loading shared libraries: libgio-2.0.so.0: cannot open shared object file: No such file or directory

    I like to run bitcoin on the machine doing the mining and I don't use a pool.  Any ideas?

    I can't verify this right now but make sure you have glib2 installed (not sure what this is in the yum repositories).  Also, from what it seems bitcoind doesn't need that library, so if you want to start mining without the GUI until I can verify this later this afternoon I would try that.

  • bitcoindaddy
    Hero Member
    *****
    Offline Offline

    Activity: 481
    Merit: 500


    View Profile
    May 09, 2011, 03:46:36 PM
     #6
    Yes, glib2 is installed. Does Bitcoin work for you on centos 5.5? If so, I'll dump 5.6 and go to 5.5.

  • stickman (OP)
    Newbie
    *
    Offline Offline

    Activity: 18
    Merit: 0


    View Profile
    May 09, 2011, 03:53:35 PM
     #7
    I've never actually run the graphical client under 5.5, only just the daemon.  Try running...

    updatedb
    ...followed by...
    locate libgio-2.0.so.0

    Do you get any output from the locate?

  • bitcoindaddy
    Hero Member
    *****
    Offline Offline

    Activity: 481
    Merit: 500


    View Profile
    May 09, 2011, 04:44:50 PM
     #8
    No output from the locate command after running updatedb.

    rpm -qa | grep glib2
    glib2-2.12.3-4.el5_3.1
    glib2-devel-2.12.3-4.el5_3.1
    glib2-2.12.3-4.el5_3.1

  • stickman (OP)
    Newbie
    *
    Offline Offline

    Activity: 18
    Merit: 0


    View Profile
    May 09, 2011, 08:16:38 PM
     #9
    Quote from: bitcoindaddy on May 09, 2011, 04:44:50 PM
    No output from the locate command after running updatedb.

    rpm -qa | grep glib2
    glib2-2.12.3-4.el5_3.1
    glib2-devel-2.12.3-4.el5_3.1
    glib2-2.12.3-4.el5_3.1


    So I got home about an hour ago and have been trying to get this figured out, but it's not looking good for CentOS.  Right now the version of Glib2 on the system is too old, and therefore doesn't have libgio.  I went ahead and pulled the glib2 source from http://ftp.gnome.org/pub/gnome/sources/glib/2.22/glib-2.22.5.tar.gz and built it using the instructions in the INSTALL file, which worked fine.  The problem I hit then was that the versions of glibc and glibc++ weren't recent enough either, so the precompiled binary threw a flag at that as well.

    After that I decided I'd just try to recompile the bitcoin binary with the versions I have on my system, but this led to more bad news because there are actually numerous other libraries I don't have.

    Right now it doesn't look good for the bitcoin client running on CentOS, but this may change when CentOS 6 comes out, which should have the more up to date libraries.  Otherwise, I'd say try Fedora, in which case the exact same steps should work, and you should actually be able to skip the python installation since Fedora should have a version already installed that is supported by poclbm.

  • bitcoindaddy
    Hero Member
    *****
    Offline Offline

    Activity: 481
    Merit: 500


    View Profile
    May 09, 2011, 10:49:18 PM
     #10
    Thanks, I was afraid of that. It doesn't look too good on Archlinux either.

    I wonder why they don't just offer a statically-linked version of the bitcoin software? That would remove a lot of the compatibility problems.

  • pwnyboy
    Full Member
    ***
    Offline Offline

    Activity: 125
    Merit: 100


    View Profile
    May 12, 2011, 09:09:23 AM
     #11
    @stickman, thanks for the guide! 

    If you're doing this frequently, you might wish to setup a kickstart file to choose all of your OS options for you, rather than having to specify things during setup.  I run a dedicated hosting company; we use kickstart to provision every CentOS box.  The procedure, even from a CD or DVD is really straight-forward.  Assuming DHCP and a non-buggy installer, invoking the setup disk1 with 'linux ks=http://www.some.com/mykickstart/ks' is all you need (and maybe an 'ip=dhcp' somewhere in there, I forget because we manually specify ip=x, dns=x, gateway=x, etc).  In our case, we use a PXE server to feed netboot images at the machines, rather than CDs, but the procedure is still the same.  Speaking of PXE, if my mining operation gets any bigger, i'll be using PXE for diskless netboot of the OS pretty soon Tongue

  • stickman (OP)
    Newbie
    *
    Offline Offline

    Activity: 18
    Merit: 0


    View Profile
    May 12, 2011, 12:08:25 PM
     #12
    Quote from: pwnyboy on May 12, 2011, 09:09:23 AM
    @stickman, thanks for the guide! 

    If you're doing this frequently, you might wish to setup a kickstart file to choose all of your OS options for you, rather than having to specify things during setup.  I run a dedicated hosting company; we use kickstart to provision every CentOS box.  The procedure, even from a CD or DVD is really straight-forward.  Assuming DHCP and a non-buggy installer, invoking the setup disk1 with 'linux ks=http://www.some.com/mykickstart/ks' is all you need (and maybe an 'ip=dhcp' somewhere in there, I forget because we manually specify ip=x, dns=x, gateway=x, etc).  In our case, we use a PXE server to feed netboot images at the machines, rather than CDs, but the procedure is still the same.  Speaking of PXE, if my mining operation gets any bigger, i'll be using PXE for diskless netboot of the OS pretty soon Tongue



    Thanks pwnyboy, I'm actually a network and systems engineer myself so I've definitely thought about PXE booting everything.  I'm booting now from USB drives because they're cheaper and use less energy.  When I made this guide I was preparing my base image to an SSD (installing directly to USB is not fun) which I then cloned to the USB using CloneZilla.  Now whenever I add a new miner I just clone my source USB and throw it in there.

  • pwnyboy
    Full Member
    ***
    Offline Offline

    Activity: 125
    Merit: 100


    View Profile
    May 12, 2011, 12:38:20 PM
     #13
    Sweet.  I've thought about using USB as well, I think the problem I'd run into is that it wouldn't work on some of my machines.  You're probably thinking to yourself "if it has a PCI-E, I can't imagine why USB boot wouldn't work".  Intel-made boards are screwy like that; everything I have that's DG965SSCK and later has issues booting and installing OSs from USB CDROMs in certain circumstances.  It's not such a stretch to think that USB sticks might present a problem.  I've found that Intel's motherboards are the highest quality hardware, and the worst quality BIOS.  Go figure.

    Out of curiosity, why was it necessary to use Clonezilla rather than conventional tools?

  • stickman (OP)
    Newbie
    *
    Offline Offline

    Activity: 18
    Merit: 0


    View Profile
    May 12, 2011, 12:57:07 PM
     #14
    Quote from: pwnyboy on May 12, 2011, 12:38:20 PM
    Sweet.  I've thought about using USB as well, I think the problem I'd run into is that it wouldn't work on some of my machines.  You're probably thinking to yourself "if it has a PCI-E, I can't imagine why USB boot wouldn't work".  Intel-made boards are screwy like that; everything I have that's DG965SSCK and later has issues booting and installing OSs from USB CDROMs in certain circumstances.  It's not such a stretch to think that USB sticks might present a problem.  I've found that Intel's motherboards are the highest quality hardware, and the worst quality BIOS.  Go figure.

    Out of curiosity, why was it necessary to use Clonezilla rather than conventional tools?

    Clonezilla makes it easier because I don't need anything else running to clone to the USB, so I can throw my source USB drive and a blank one in the new machine, clone it, and then boot it up, without needing another system or drive.  I went through a lot of trial and error trying to get USB booting to work, though the biggest problem I ran into (besides the fact that installing directly to USB is a pain in the ass) is that if you clone from a regular drive to a USB drive, you'll need to rebuild the initrd image.  Here's a link to the process I found that fixed the problems I was having when doing that in case anyone tries:

    http://www.linkedin.com/answers/technology/information-technology/information-storage/TCH_ITS_IST/607200-41071711

    Also, I wouldn't recommend LVM in this case, because Clonezilla isn't optimized for copying LVM partitions.

  • pwnyboy
    Full Member
    ***
    Offline Offline

    Activity: 125
    Merit: 100


    View Profile
    May 12, 2011, 01:08:11 PM
     #15
    Actually when I mentioned conventional tools, I was thinking along the lines of:

    1) with a fully booted system, create a partition and fs on the new USB stick
    2) dd if=/path/to/boot/blocks/for/usbstick.bin of=/dev/sdx (makes the USB stick bootable)
    3) mountdev/sdx1mnt
    4) cp -ar*mnt

    Presumably the boot blocks for the USB stick would've come from a 'dd' of the first 512 bytes of another working USB stick.  Curiosity has now gotten the best of me; I think I should try this in my spare time.

  • stickman (OP)
    Newbie
    *
    Offline Offline

    Activity: 18
    Merit: 0


    View Profile
    May 12, 2011, 01:44:03 PM
     #16
    Quote from: pwnyboy on May 12, 2011, 01:08:11 PM
    Actually when I mentioned conventional tools, I was thinking along the lines of:

    1) with a fully booted system, create a partition and fs on the new USB stick
    2) dd if=/path/to/boot/blocks/for/usbstick.bin of=/dev/sdx (makes the USB stick bootable)
    3) mountdev/sdx1mnt
    4) cp -ar*mnt

    Presumably the boot blocks for the USB stick would've come from a 'dd' of the first 512 bytes of another working USB stick.  Curiosity has now gotten the best of me; I think I should try this in my spare time.

    Yeah, I thought of trying that, but once I found something that worked I decided to stick with it Wink  Thanks, hopefully I'll get a chance to try that sometime

  • pwnyboy
    Full Member
    ***
    Offline Offline

    Activity: 125
    Merit: 100


    View Profile
    May 17, 2011, 06:19:17 PM
     #17
    FYI, I've come up with a method under Fedora 14 that is _much_ easier, as it already has Python 2.7, NumPy and JSON support built into the existing OS RPMs.  Same with git, python-twisted (needed for Phoenix) and probably some other things I'm not thinking of.  I've gotten the provisioning down to a simple kickstart, ATI driver install, SDK install, PyOpenCL and the miner.   The SDK is RPM'able, and the drivers do exist in the wild according to my googling (maybe included with FC14 also?).

    Will produce a guide, including a kickstart file, when things settle down.. if that should ever happen.

  • error
    Hero Member
    *****
    Offline Offline

    Activity: 588
    Merit: 500



    View Profile
    May 17, 2011, 07:59:33 PM
     #18
    Quote from: pwnyboy on May 17, 2011, 06:19:17 PM
    FYI, I've come up with a method under Fedora 14 that is _much_ easier, as it already has Python 2.7, NumPy and JSON support built into the existing OS RPMs.  Same with git, python-twisted (needed for Phoenix) and probably some other things I'm not thinking of.  I've gotten the provisioning down to a simple kickstart, ATI driver install, SDK install, PyOpenCL and the miner.   The SDK is RPM'able, and the drivers do exist in the wild according to my googling (maybe included with FC14 also?).

    Will produce a guide, including a kickstart file, when things settle down.. if that should ever happen.

    It's in RPM Fusion (again). Just install akmod-catalyst and it will pull in everything you need (except for the Stream SDK).
    3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8

  • EPiSKiNG
    Legendary
    *
    Offline Offline

    Activity: 800
    Merit: 1001



    View Profile
    May 17, 2011, 09:23:53 PM
     #19
    Quote from: stickman on May 08, 2011, 02:34:29 AM
    So I've had a text file I've been using when setting up new miners under CentOS 5.5, and I figured I'd share it with the community.  Everyone seems to be using Ubuntu, which is great, but I've only run into problems when trying to get everything configured in Ubuntu.  For me, CentOS has been much easier than Ubuntu, so here goes:

    First off, when I install CentOS I choose only the Server GUI package group which I then customize by clicking the Customize Now radio button.  I then deselect everything under the Servers group, and make sure I select Development Libraries and Development Tools (or something like that).  This guide starts off after logging into the system after a fresh install.

    Install ATI Drivers:
    wget http://www2.ati.com/drivers/linux/ati-driver-installer-11-4-x86.x86_64.run
    sh ati-driver-installer-11-4-x86.x86_64.run
    <go through the install process>
    aticonfig --adapter=all --initial --force


    Install and configure AMD APP SDK
    wget http://download2-developer.amd.com/amd/APPSDK/AMD-APP-SDK-v2.4-lnx64.tgz
    tar -xf AMD-APP-SDK-v2.4-lnx64.tgz
    cd AMD-APP-SDK-v2.4-lnx64
    cp lib/x86_64/*lib64/
    cp icd-registration.tgz
    cd
    tar -xf icd-registration.tgz
    rm -f icd-registration.tgz
    cd ~
    echo AMDAPPSDKROOT=/root/AMD-APP-SDK-v2.4-lnx64 >> .bashrc
    echo AMDAPPSDKSAMPLESROOT=/root/AMD-APP-SDK-v2.4-lnx64 >> .bashrc
    echo LD_LIBRARY_PATH=/root/AMD-APP-SDK-v2.4-lnx64/lib/x86_64 >> .bashrc

    Install Python 2.7
    wget http://www.python.org/ftp/python/2.7.1/Python-2.7.1.tgz
    tar -xf Python-2.7.1.tgz
    cd Python-2.7.1
    ./configure
    make && make install
    cd ~

    Install NumPy
    wget http://downloads.sourceforge.net/project/numpy/NumPy/1.6.0b1/numpy-1.6.0b1.tar.gz
    tar -xf numpy-1.6.0b1.tar.gz
    cd numpy-1.6.0b1
    python setup.py install
    cd ~

    Install PyOpenCL
    wget http://pypi.python.org/packages/source/p/pyopencl/pyopencl-2011.1beta3.tar.gz
    tar -xf pyopencl-2011.1beta3.tar.gz
    cd pyopencl-2011.1beta3/
    python configure.py \
      --cl-inc-dir=/root/AMD-APP-SDK-v2.4-lnx64/include \
      --cl-lib-dir=/root/AMD-APP-SDK-v2.4-lnx64/lib/x86_64 \
      --cl-libname=OpenCL
    python setup.py install
    cd ~

    Install JSON-RPC
    svn co http://svn.json-rpc.org/trunk/python-jsonrpc
    cd python-jsonrpc/
    python setup.py install
    cd ~

    Install Git
    wget http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm
    rpm -i epel-release-5-4.noarch.rpm
    yum install git -y

    Clone latest poclbm
    git clone git://github.com/m0mchil/poclbm.git
    -or-
    git clone https://github.com/m0mchil/poclbm.git

    REBOOT
    reboot

    TA DA!  After you reboot, you should be able to run poclbm and start mining!  Please let me know if there's anything I can change here to improve this guide, or if anyone has any problems when using this.  Using this method I'm currently able to mine at 375 Mh/s on a 5870 clocked @ 900 MHz.


    +1 for a linux guide!!! Makes it easier on us M$ people.  Thanks!!

    -EP
    YOU CAN TRUST ME! EPiSKiNG-'s COINS!! BUYING SELLING BTC - USA --- View my OTC Trading Feedback!!
    <gribble> You are identified as user EPiSKiNG-, with GPG key id 721730127CD7574D, key fingerprint EBFC267F8F10EFD1FB84854D721730127CD7574D, and bitcoin address 1EPiSKiNG139bzcwTm8rxMFNfFFdanLW5K

  • pwnyboy
    Full Member
    ***
    Offline Offline

    Activity: 125
    Merit: 100


    View Profile
    May 18, 2011, 06:50:52 AM
     #20
    Quote from: error on May 17, 2011, 07:59:33 PM
    It's in RPM Fusion (again). Just install akmod-catalyst and it will pull in everything you need (except for the Stream SDK).

    Yeah I discovered that a little earlier.  What's odd is that none of my systems seem to be updating grub.conf to point to the updated 2.6.35.13 kernel (pulled in by the regular Fedora update repos).  The RPM Fusion kmods need this version because of magic number congruency in the kernel.  Thus the benefits of having an all-in-one kickstart script are somewhat nullified since you've got to hack on grub.conf manually.  I haven't looked into the kernel RPMs to see if this is some kind of scripting error during the update, but in any event, I feel like it would confuse Linux newbies too much if I made such a guide under the circumstances :/
    Pages: [1] 2 »  All
      Print  
Page 1
Viewing Page: 1

IRLBTC™ © 2025 IRLBTC.com