Topic: Official FutureBit Apollo BTC Software/Image and Support thread - page 11. (Read 52508 times)

yes, it should say 168,473/870397, or some such number. its not growing. and i just got up and still at 168,473. i have it plugged in to ethernet. yes, im mining, but i know it prob doesnt matter since it cant mine if its not on the right block lol

follow the futurebit instructions online.
https://www.futurebit.io/flashing-sd-card

I picked up the same micro card mentioned. Thursday. I have a PC with two SD card slots. What program did you use to clone the old card to the new please?

It should not be stuck? mine would show ( eg) 253000/870397,  first number should grow slowly every few mins as it sync's with the blockchain and second number as new blocks are found, is either one changing? f your also show 0% thats not right. are you mining with it? are you using Wi-Fi or Ethernet cable?

Looking at the debug.log in the bitcoin directory is the most important item to monitor actively.  An error message on the node GUI doesn't show you what's going on behind the scenes.  Did the node abruptly stop?  what errors? chainstate corrupt?

Do you have the browser open on the Node?  I close the browser and have minimal items on the node open to monitor the logs.  The node IBD performed better on my system with these closed.  I stopped the miner until download complete.   I monitor remotely as this only grabs basic data from the node. saves RAM

with the system monitor check the operating processes.  Sometimes the bitcoind process may still be running even though the system looks paused.  only when this process disappears is the node completely stopped.  You can get an error message in the logs that memory buffer exceeded limits and the bitcoind then writes the data to the chainstate database and continues on.  There is a pause when this happens.

ok, so itll be stuck at 0% for a while, then itll kick in. so check in am?

thx bro

I got mine last week and it took about 3-4 days to load the blockchain up.

just received an apollo 2. why does my node say max btc block is 168,473?

also shouldnt ut take a bit to load node?

thx

its been stuck on 168,473 the whole time. but it keeps showing a found block. but when i connect my node to sparrow, it says connection to btc core successful, but it is still syncing, but its not going past 0%

Could you please clarify the instructions for this? I'm only moderately experienced with this but I am having the same issue but only getting about 25% synced before I hit the error message.

Sounds good and some say that should work, but the con to this is you have a duplicate blockchain from another node.  Each node creates its own database set.  The theory is copies can create risk of exposure to bad actors.  But from your own device should be ok.  Now, with the new copy of the database is the Node a different bitcoin node address or does it take on the same node address when copying that data?

Using a USB to pcie, I don't think the memory card will overheat as your limited to USB 3.0 speeds which is less than the actual memory card speeds.  No overheat here.  200mbps read/write through usb 3.0

directories in your linux raspberry pi is main bitcoin directory  media/pcie/Bitcoin.   The usb drive is media/futurebit.  I am very careful when opening windows and copying files on the node. I look at file properties to make sure I'm pointed to the right drive.

I just had a chainstate file get corrupted, chainstate file xxxxxx is corrupt.  possible system crash.  Tried to recover it. multiple node restarts failed.  reindex-chainstate=1.  That will delete all chainstate files on restart and rebuild the chainstate from start.   Bitcoin database stays intact.  I find the database blockchain files seem to be ok and no errors detected.  This process takes too long and My Node can't seem to cleanly rebuild it with anything else running such as the miner or open browser windows.  It seems to crash more.  If it crashes and you have the reindex-chainstate=1 set it will start from scratch every time.  have to delete this setting before any node restart after chainstate files have been deleted.  bitcoin will reindex chainstate files on restart even with this setting turned off.

So, what I did, which is quicker is take my backup nvme card and delete the chainstate files on the node that have a corrupt file and reinstall only the chainstate backup files to the node nvme.  On restart chainstate files are rebuilt from missing 3 weeks.

Yes, I didn't have the miner or node runnng.  Took a few hours to rebuild the missing chainstate from 3 weeks ago.  Now back to normal.  Node running ok and time to backup the files to todays date.  about a 45 to 60 minute time.  Carefully delete the usb nvme files and copy a fresh set.

How I can tell is when I shut down the node I look for a clean exit in the debug.log.  If there is a chainstate error it shows there.

Here’s a quick guide:

- Use MiningRigRentals (MRR) for more flexibility compared to NiceHash.
- Ensure your FutureBit node is configured to accept external connections (set up port forwarding and secure access).
- Rent hashpower from MRR and input your node’s IP and port into the rental settings.
- Keep an eye on the performance to ensure everything is running smoothly.

Your guess is just as good as mine. We dont collect user data for this reason. If we get big enough where people are finding a block every day I would not be surprised if the powers that be come knocking on our doors requesting data on where these blocks are coming from.

The only thing we know 100% is that the block was found by someone running an Apollo BTC or Apollo II through the solo mode feature.

Is it possible to rent hashpower from say Nicehash or MRR and point that hashpower to my futurbit node? How would I go about doing that? Thanks everyone

Glad I helped! Like they say, even a blind squirrel finds an acorn once in a while.

Now I can thank you for your help! It never occurred to me to go into my modem and set the port forwarding as well as on the router itself. BINGO!!! It worked! I have more connections now than I've ever had in the past.

With regards to you not accessing the bitnodes website anymore, I can only guess that it may be related to your browser cache. Try clearing that site from your cache and/or try accessing the site from a different browser and/or computer. I don't have a problem accessing that site after all the monkeying around I did with the router and modem.

Cheers!

Thanks for this. Its what I'll be attempting. Except I'll have the drives connected to the Apollo rather than a different PC.

/blocks  &  /chainstate
OK I haven’t done this before but I have been reading about copying the Bitcoin Core blockchain to another system and this is what I plan to do when I receive my Apollo II later this week.
I have a fully synched v22 Bitcoin Core node running on an Ubuntu PC that I’ve been playing with and I will copy it over to the new 2 TB SSD to avoid re-downloading the entire blockchain again, which might take me a week.
Bitcoin is installed on my Ubuntu PC in the home directory in the hidden folder .bitcoin. There are three subfolders within .bitcoin,   /blocks, /chainstate  & /wallets.
/blocks is 699.6 GB
/chainstate is 12.5 GB
I will not be moving over the /wallets folder or the individual files in the .bitcoin folder, files like bitcoin.conf mempool.dat, peers.dat... These are specific to that PC install and I believe the ones on the Apollo II system will already be in place or will be created on statrtup.
So basically I am moving over just two folders under the .bitcoin folder,  /blocks  &  /chainstate. That’s it.
Here’s what I plan to do when I receive the system.
Connect a monitor, keyboard and mouse. Power on and log into the Apollo system with minimum configurations settings. Stop the miner and node if they are running. Use a file manager on the desktop to make sure the file structure is the same on the SSD,  “cd /media/nvme/bitcoin” to look for the blocks and chainstate folders. If they are there then rename them to oldblocks and oldchainstate just to save them for now. Shutdown the system, remove the SSD and put on a USB/pcie adapter into my Ubuntu PC. I will put a fan blowing on the SSD during this copy as this will probably be the most work this SSD will ever experience, copying 700+ GB to it in one go. Obviously the Bitcoin Core node will not be running on my PC to ensure the files are all closed properly. After a successful copy, shutdown the PC, move the SSD back over to the Apollo II system and power it on and complete the setup.

I think it will work. Maybe someone else can chime in if this process looks reasonable or if I’ve left something out. Hope this helps. Good luck mining...

A follow up question about doing IBD and overcoming what seems to be too much stress for the RAM & processor.

I've got a backup NVME with about the first-half of the IBD on it. I would like to see if there's advice on the procedures for starting a node (Apollo BTC installing 2.0.5) by using the backed-up blockchain data.

Its a 2TB NVME drive in the node, with a 1TB NVME connected via USB and a flashed micro SD to install the system.

Questions are things like which folders need to go over and in what order should steps be taken from initial boot. Thank you!

I wanted to thank you again for your help and give an update. After getting the blockchain totally sync'd I was still only getting 10/32 and sometimes 11/32. I added 7 nodes from bitnodes.io and was only getting 11/32. I had port forward on my Eero to 8333 but wasn't until finding where my port forward on my main modem was able to add the 8333 there and my Appllo started getting 32/32 nodes.  For some reason, i can't access bitnodes.io anymore, I get a 403 forbidden notice, I am not sure what that is about?

Seems so to me as well. I forwarded the port from my router already. Maybe I did something wrong. Can anyone help me?



EDIT: I got it to work, the problem is you need to set a static IP first before port forwarding. I hope this can help someone else!