Topic: bitcoind for ARM / Cubieboard / Raspberry Pi (Read 6988 times)

Hi Guys,

I know I might be a bit late but I was trying to run a bitcoin full node on my cubieboard3 (cubietruck) and I am struggling a lot! Let's go with my questions ans see if someone is kind to asnwer me

1 - What is the minimal version of ubuntu that I need to have to run a full node?
2 - I was able to install Ubuntu Desktop 12-04 LTS and tried to install the full node. When I was click on the Bitcoin UI nothing happened. Could be because of the version for the Bitcoin core Vs the Ubuntu version?
3 - I did an update from 12-04 LTS to 14-04 LTS but since I installed the updagrade I couldn't login anymore. I actually got a warning during the installation saying that the "Unity" could not work. I ignored and continued but seems that something is wrong...
4 - Is there any other Operating System (other then Ubuntu) or something similar where I could run a full node on this cubietruck?

Here are the specs for the cubietruck (Cubieboard3):

SoC: Allwinner A20
CPU: ARM Cortex-A7 @ 1 GHz dual-core
GPU: Mali-400 MP2
display controller: unknown, supports HDMI 1080p, no LVDS support
2 GiB DDR3 @ 480 MHz
8 GB NAND flash built-in, 1x microSD slot, 1x SATA 2.0 port (Hard Disk of 2,5").
10/100/1000 RTL8211E Gigabit Ethernet
2x USB Host, 1x USB OTG, 1x CIR.
S/PDIF, headphone, VGA and HDMI audio out, mic and line-in via extended pins
Wi-Fi and Bluetooth on board with PCB antenna (Broadcom BCM4329/BCM40181)
54 extended pins including I²C, SPI
Dimensions: 11 cm × 8 cm

Thank you very much.
Cheers.

Has anyone tried running Bitcoind AND a LAMP server on their cubieboard/pi/beaglebone?

Reindex on rpi only took a day or two IIRC...
Also, i wouldn't recommend writing on an SD card; just use a simple old external harddrive. (with seperate power supply, ofcourse)

Has anyone managed to get my debs working on a Cubieboard 2? I'm having trouble and I'm assuming it's something to do with bitcoind using two threads as it's a dual core machine. debug.log reports pthread errors like:

According to a friend of mine, a full reindex on the Pi took 4-5 days.

Full reindex took a little more than 48h (I think about 96h), but now it's done and bitcoind works fine on my BeagleBone Black right now.
I will try to copy over this blockchain to RPi and see if it will work there. I had same problem with it before I bought BBB, but since RPi has twice slower CPU, indexing in there would take ages. Yet, maybe with readymade index it will work now.

IO is still a concern, I'm not sure how lond SD card would live with bitcoind running constantly on it. But I will find out, eventually.

you cant mix different arch's of leveldb databases!

Unfortunately it doesn't work at all on my Debian. I'm not sure what's wrong or if I made a mistake somewhere, but here is what I did:
1) I've installed a fresh Debian wheezy and installed all these debs (apart from bitcoin-qt as I need no GUI).
2) I've copied over whole blockchain from a windows machine with updtodate BitcoinQt 0.8.5
3) I started bitcoind with my custom config:
Bitcoind starts, but it:
a) always asking for database reindex and doesn't pick the index I've copied;
b) if I start it with -reindex flag - it hangs in processes with max CPU, but it doesn't respond over JSON-RPC, and even after a long time waiting shows no signs of life, so I have to just kill it.

However, I found something interesting elsewhere. Debian Unstable repo has bitcoind package available for armhf/armel architectures, and it's last 0.8.5 version. So I installed it and it works nearly fine. Unfortunately it still doesn't like my index copy, but when I run it with -reindex - it start fine, responds over JSON-RPC and indexing goes on, I see it by the quickly increasing blocks count. Full reindex will take I think 24-48h, but I hope it will work fine afterwards.

I might be able to decrease the requirements in the Debian control file, but I would need somebody to confirm whether 1.48 and 1.49 would be compatible and whether there are likely to be any linking issues.
That should work as it's what the debs were designed for. You still could well struggle with only 512 MB RAM though (at least for downloading the blockchain).

I was just trying to install these .debs on Ubuntu 12.04 at Beaglebone Black, but it doesn't work. Basically ubuntu repos for ARM have libboost version only 1.48 available, while these debs require 1.49. It probably can be compiled from sources, but that's not as simple as just installing some ready packages and also will probably take much time on a weak ARM CPU.

Trying Debian Wheezy on the same hardware.

Yes, running for 10 hours and now at block 216931

That's really the point of my .debs - compiling DB 4.8 is a bit of a pain but I wanted binary compatibility. It does work rather well though, doesn't it.

I compiled it myself on the new cubieboard3 and is running now (I'm using BDB5.1 as I don't know how to do it with 4.8. I'm not using the wallet, anyway)

Surely then you're just saying that using SSDs have no real use in the industry (considering that their real benefit is in random I/O, and wear levelling is similar to writes being spread over the disk)?

Either way, this is all a bit off topic now. All I can say is that good quality SSDs seem to work very well for databases in my professional (hosting services) capacity, and combined with a Cubieboard, it's been running very stable now with an uptime of two weeks and not a single issue.

this is a issue of any NAND device so far, "wear levelling" is just a nasty workaround (which often dosnt work well)

I am working a project like this too so I'd like to know if the SD card will be ok or not. Also how long will a 32Gb card last us with the growing blockchain?

So I imagine this is more of an issue with SD cards then? I think most SSDs have wear levelling (hence they're used for all sorts of IO intensive operations, and often for databases with few issues).

LevelDB is designed for hard disks, not SSDs. It's not only about writing blocks when they arrive but updating the databases too.

Are you sure? Blockchain writes don't typically write over the same area of card. You'll record block information, and then just leave it sitting there.

I recommend running from a SSD anyway as they're so much quicker and more reliable.

be aware that this is a sure way to kill your SD Card