CentOS 5.5 Mining Guide for ATI/poclbm

[stickman]

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.

[1713464799]

1713464799

[1713464799]

1713464799

[1713464799]

1713464799

[1713464799]

1713464799

[error]

I find it's better to git clone the miner, as it makes it much easier to update later.

[stickman]

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

[bitcoindaddy]

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]

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]

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]

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]

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]

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]

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]

@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

[stickman]

@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

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]

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]

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]

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) mount /dev/sdx1 /mnt
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]

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) mount /dev/sdx1 /mnt
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   Thanks, hopefully I'll get a chance to try that sometime

[pwnyboy]

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]

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).

[EPiSKiNG]

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

[pwnyboy]

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 :/