Pages:
Author

Topic: CentOS 5.5 Mining Guide for ATI/poclbm (Read 19497 times)

hero member
Activity: 924
Merit: 501
April 09, 2013, 02:06:57 AM
#29
based on this thread which I've followed more than once I wrote an updated step by step CentOS bitcoin mining guide.  I hope you find it useful and if the OP is around, maybe you'll consider locking this dated thread.
full member
Activity: 406
Merit: 100
September 05, 2011, 09:04:45 AM
#28
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.
It is my understanding that CentOS 6 has made its appearance already.
Did anyone already try to get the bitcoin client running?
sr. member
Activity: 467
Merit: 250
September 01, 2011, 06:51:47 PM
#27

Changes needed to be current with version changes:

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

Install PyOpenCL
wget http://pypi.python.org/packages/source/p/pyopencl/pyopencl-2011.1.2.tar.gz
tar -xf pyopencl-2011.1.2.tar.gz
cd pyopencl-2011.1.2/
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
bzr checkout http://bzr.json-rpc.org/trunk
cd trunk/python-jsonrpc/
python setup.py install
cd ~

full member
Activity: 406
Merit: 100
July 15, 2011, 08:22:54 PM
#26
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.
Hi, did things already 'settle down' a bit?
I'm planning to install poclbm (or maybe phoenix as someone claimed it gives 4-5% more output) on the newest fedora but it's the first time I do mining, so a guide would be very helpful.
Thanks Cool
sr. member
Activity: 313
Merit: 251
Third score
June 30, 2011, 04:18:26 AM
#25
Thanks to all the advice in the thread, I just managed to add an HD5770 in my old office PBX PC (running CentOS and Asterisk) and add a bit to my mining capacity. PBX still functions perfectly as well. I can confirm that things work better with the latest 11.6 driver at least for this card.

A note that might be of help to anyone else trying this:

For some reason, I had to copy all the library files under /root/AMD-APP-SDK-v2.4-lnx32/lib/x86 to /usr/lib. In any other case pyopencl would not load.

Also, since I found out that phoenix miner gets an extra 3-4% out of the card, I installed it and using it. The only addition needed is the Twisted framework which can be installed as easy as:

wget http://twistedmatrix.com/Releases/Twisted/11.0/Twisted-11.0.0.tar.bz2
bunzip2 Twisted-11.0.0.tar.bz2
cd Twisted-11.0.0
python setup.py install
cd ..

Getting 213 MH/s right now, with card at 950,300 and 65 C temp.
full member
Activity: 125
Merit: 100
Maybe try with a different driver version, or different tool (like ATIOverdriveCtl).
newbie
Activity: 12
Merit: 0
my problem configuring


Adapter 0 - ATI Radeon HD 5900 Series
            Sensor 0: Temperature - 51.00 C

Adapter 1 - ATI Radeon HD 5900 Series
            Sensor 0: Temperature - 51.50 C
ERROR - Get temperature failed for Adapter 2 - ATI Radeon HD 5900 Series

Adapter 3 - ATI Radeon HD 5900 Series
            Sensor 0: Temperature - 58.00 C
ERROR - Get temperature failed for Adapter 4 - ATI Radeon HD 5900 Series

Adapter 5 - ATI Radeon HD 5900 Series
            Sensor 0: Temperature - 59.50 C

not temperature reader in adapter 2,4
full member
Activity: 125
Merit: 100
The miner can be ran from the shell.  However my understanding is that you need to start X to initialize the video card and that there's no getting around it.  Fortunately you can run a very simplified non-intrusive version of X on the console.

For example, this is the way I mine headless (without needing a keyboard/video/mouse) via an ssh session:

Quote
# xinit -e twm &
# export DISPLAY=:0.0
# aticonfig --odsc=990,900
# screen -t (some name for this miner) python phoenix.py blah blah

That will start xwindows with twm running on the console (twm is not included in the X Window System group by default, you'll need 'yum -y install xorg-x11-twm').  Then you can screen the miner.  This is particularly helpful when you have several mining rigs, or several GPUs in one box.  Hope that helps.
member
Activity: 73
Merit: 10
Thanks for this.

I ran into this with centos myself but I didn't think about using fedora.  Will do that.  I myself am more comfortable with using rpm type OS Wink

Are you guys running xwindows or just shell?  I assume you need xwindows for the bitcoin client.  But since I either plan to run this on remote pools such as slush or deepbit or my own personal pool, I'm assuming this is all ok.
full member
Activity: 125
Merit: 100
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 :/
legendary
Activity: 800
Merit: 1001
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

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
hero member
Activity: 588
Merit: 500
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).
full member
Activity: 125
Merit: 100
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.
newbie
Activity: 18
Merit: 0
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 Wink  Thanks, hopefully I'll get a chance to try that sometime
full member
Activity: 125
Merit: 100
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.
newbie
Activity: 18
Merit: 0
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.
full member
Activity: 125
Merit: 100
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?
newbie
Activity: 18
Merit: 0
@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.
full member
Activity: 125
Merit: 100
@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

hero member
Activity: 481
Merit: 500
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.
Pages:
Jump to: