3

I have a Geekbox (geekbox.tv) and I'm trying to run a full node on it. I installed the Lubuntu 14.04 only OS (removed the Android partitions), but considering that only gives 14GB of hard drive space, I am attempting to run it from an SD card. I am using the ARMv7 CLI.

(even though the Geekbox is 64-bit, it won't run the ARMv8 build ('unable to execute: no such file or directory'), but runs the v7 build...albeit with the below problem)

I formatted the SD card as exFAT and copied the up to date data.mdb from my other computer (Mac).

The Geekbox is a bit slow, but when I run monerod, the daemon goes through the process and gets to the sync feedback. The node then just steadily falls back ("your node is 28 blocks behind", "your node is 29 blocks behind", etc).

I don't know how to fix this. I have heard that others have successfully run a node on a Geekbox, so I wonder if its either:

  • requiring hardware optimisation - can I speed up the Geekbox somehow?
  • a permissions problem - I have read that the problem might be with the exFAT formatted SD card, but haven't found solutions.
  • probably something else...

Having said that, here are some of the errors churned out on log level 1:

2017-04-11 10:48:10.640 [P2P0]  ERROR   verify  src/cryptonote_core/blockchain.cpp:3185 Block with id: <c3e7ba78f99e10ed95c90da247e148e8db03115d3bd2a52c10b278595026e16a>
does not have enough proof of work: <c3993773c21d03ef2fe3b8b24ec3bd603aa4da49bc1a96a037857f9daf87a8b1>
unexpected difficulty: 9857023396

2017-04-11 10:48:15.618 [P2P9]  ERROR   net.p2p src/p2p/net_node.inl:1504   [37.59.51.212:28080 OUT] COMMAND_REQUEST_SUPPORT_FLAGS invoke failed. (-4, LEVIN_ERROR_CONNECTION_TIMEDOUT)

2017-04-11 10:50:06.944 [P2P9]  WARN    net.p2p src/p2p/net_node.inl:1442   [0.0.0.0:0 OUT] back ping connect failed to 149.56.187.7:18080

But when I run 'status', I have both incoming and outgoing connections.

I have tried syncing from scratch, which works, but would take weeks due to how slow it was going! I also exported the blockchain.raw and imported, but it threw some errors at the end and started syncing from the start of the blockchain:

2017-04-11 10:34:44.854         f758b000    FATAL   bcutil  src/blockchain_utilities/blockchain_import.cpp:505  Failed to add block to blockchain, verification failed, height = 4
2017-04-11 10:34:44.856         f758b000    FATAL   bcutil  src/blockchain_utilities/blockchain_import.cpp:506  skipping rest of file

I should also point out that I'm a Linux noob. Any help or suggestions would be great :)

2 Answers 2

5

It sounds like your 32 bit Monero build is invalid, it is computing incorrect hashes and failing to accept valid blocks. If you got this from the official download site, please submit an issue on Github about this.

You are wasting power running a 32 bit OS. I'm currently using this 64 bit Debian install: http://forum.geekbox.tv/viewtopic.php?f=12&t=3284

3
  • Thanks hyc. I installed the 64-bit Debian image and set everything up again with the ARMv8 build from the getmonero.org site and...it does exactly the same! Falls back on blocks. Can't sync. Very strange. I have only tried this from a copy of the lmdb data file from my Mac. I am now trying an import from an export from my Mac. This hasn't thrown an error yet like in the OP so we'll see. It's slow though. I'll post back in several weeks once it's done :-o The positive thing is that Debian seems a lot quicker than 32-bit Lubuntu, so thanks also for that. Commented Apr 13, 2017 at 23:33
  • Actually just started again without verifying (as I trust myself as the source). Should hopefully be done in hours instead of days. Thanks Monero.How monero.how/tutorial-how-to-speed-up-initial-blockchain-sync Commented Apr 13, 2017 at 23:53
  • I now have Debian installed and a 100% synced node. I should also say that I reformatted my 64gb Sandisk SD card to EXT2 from exFAT and that generally sped reading, writing and therefore syncing. Thanks again hyc. Whilst this didn't fix the problem with the original infrastructure, the answer started my off in getting a full node working, so I'll give it a tick. Commented Apr 18, 2017 at 10:11
1

There is a known issue where sync does not catch up with slow network speeds. Have you tried reducing the block sync size? See this answer and this issue

1
  • I didn't know about this. Thanks for letting me know. Even though I solved my issue by installing a better OS for my linux box, it occasionally falls behind on a few blocks. I have added '--block-sync-size 20' to the CLI startup commands to see if this helps keep it up to speed. Commented Jun 27, 2017 at 14:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.