stickman (OP)
Newbie
Offline
Activity: 18
Merit: 0
|
|
May 08, 2011, 02:34:29 AM Last edit: May 08, 2011, 08:10:23 AM by 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.runsh ati-driver-installer-11-4-x86.x86_64.run <go through the install process> aticonfig --adapter=all --initial --force Install and configure AMD APP SDKwget http://download2-developer.amd.com/amd/APPSDK/AMD-APP-SDK-v2.4-lnx64.tgztar -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.7wget http://www.python.org/ftp/python/2.7.1/Python-2.7.1.tgztar -xf Python-2.7.1.tgz cd Python-2.7.1 ./configure make && make install cd ~ Install NumPywget http://downloads.sourceforge.net/project/numpy/NumPy/1.6.0b1/numpy-1.6.0b1.tar.gztar -xf numpy-1.6.0b1.tar.gz cd numpy-1.6.0b1 python setup.py install cd ~ Install PyOpenCLwget http://pypi.python.org/packages/source/p/pyopencl/pyopencl-2011.1beta3.tar.gztar -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-RPCsvn co http://svn.json-rpc.org/trunk/python-jsonrpccd python-jsonrpc/ python setup.py install cd ~ Install Gitwget http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpmrpm -i epel-release-5-4.noarch.rpm yum install git -y Clone latest poclbmgit clone git://github.com/m0mchil/poclbm.git -or- git clone https://github.com/m0mchil/poclbm.gitREBOOTreboot 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
|
|
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.
|
3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8
|
|
|
stickman (OP)
Newbie
Offline
Activity: 18
Merit: 0
|
|
May 08, 2011, 07:33:24 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
|
|
|
|
bitcoindaddy
|
|
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?
|
|
|
|
stickman (OP)
Newbie
Offline
Activity: 18
Merit: 0
|
|
May 09, 2011, 03:32:26 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
|
|
May 09, 2011, 03:46:36 PM |
|
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
Activity: 18
Merit: 0
|
|
May 09, 2011, 03:53:35 PM |
|
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
|
|
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
|
|
|
|
stickman (OP)
Newbie
Offline
Activity: 18
Merit: 0
|
|
May 09, 2011, 08:16:38 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
|
|
May 09, 2011, 10:49:18 PM |
|
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
|
|
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
|
|
|
|
stickman (OP)
Newbie
Offline
Activity: 18
Merit: 0
|
|
May 12, 2011, 12:08:25 PM |
|
@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
|
|
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?
|
|
|
|
stickman (OP)
Newbie
Offline
Activity: 18
Merit: 0
|
|
May 12, 2011, 12:57:07 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-41071711Also, I wouldn't recommend LVM in this case, because Clonezilla isn't optimized for copying LVM partitions.
|
|
|
|
pwnyboy
|
|
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) 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 (OP)
Newbie
Offline
Activity: 18
Merit: 0
|
|
May 12, 2011, 01:44:03 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) 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
|
|
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.
|
|
|
|
error
|
|
May 17, 2011, 07:59:33 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
Activity: 800
Merit: 1001
|
|
May 17, 2011, 09:23:53 PM |
|
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.runsh ati-driver-installer-11-4-x86.x86_64.run <go through the install process> aticonfig --adapter=all --initial --force Install and configure AMD APP SDKwget http://download2-developer.amd.com/amd/APPSDK/AMD-APP-SDK-v2.4-lnx64.tgztar -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.7wget http://www.python.org/ftp/python/2.7.1/Python-2.7.1.tgztar -xf Python-2.7.1.tgz cd Python-2.7.1 ./configure make && make install cd ~ Install NumPywget http://downloads.sourceforge.net/project/numpy/NumPy/1.6.0b1/numpy-1.6.0b1.tar.gztar -xf numpy-1.6.0b1.tar.gz cd numpy-1.6.0b1 python setup.py install cd ~ Install PyOpenCLwget http://pypi.python.org/packages/source/p/pyopencl/pyopencl-2011.1beta3.tar.gztar -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-RPCsvn co http://svn.json-rpc.org/trunk/python-jsonrpccd python-jsonrpc/ python setup.py install cd ~ Install Gitwget http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpmrpm -i epel-release-5-4.noarch.rpm yum install git -y Clone latest poclbmgit clone git://github.com/m0mchil/poclbm.git -or- git clone https://github.com/m0mchil/poclbm.gitREBOOTreboot 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
|
|
May 18, 2011, 06:50:52 AM |
|
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 :/
|
|
|
|
|