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

I am glad you recommended checking the MicroSD card but its about 70% sync'd now. It shows 10/32 connections, but the instructions say it should go higher (to the 32 I guess), so will it not go higher until 100% sync'd or do I need to do something.

It is but we are still building the images.

Sorry guys dropped the ball on this update. Last two weeks with the block find and trump winning has been pretty crazy so trying to stay on top of production and support.

I dont want to push the OTA update until we have the images ready in case there are update failures. Going to have those out Monday or Tuesday.

Is this ready for public release yet?

Thanks I will wait for it sync and yes i plan on using ethernet cable

First thing, make sure both the MicroSD card and the NVME card are seated all the way before you even plug it in. Then after you get it up and running (preferably hard-wired with an ethernet cable) I would let the node sync up fully (could be several days) before trying to mine beyond ECO mode. Besides, you can't mine to your own node until it is sync'd completely - but you can pool mine, just stay in ECO until the node is complete. Anything higher than ECO during the sync really puts a strain on the system. That's pretty much it in a nutshell.

Here is the full getting started guide on the Futurebit website:
https://static1.squarespace.com/static/5a9c84ac89c172bcf087f4c0/t/662173d150d84b057cb14192/1713468369163/FutureBit-Apollo-II-Guide.pdf

Cheers!

I am waiting on FedEx to drop off my Apollo II full node. Any tips on setting it up that you might have. Should I let the node populate the blockchain before doing anything else?

@ Any Apollo II Gurus,

I have a question about what should have been a simple configuration but it stumped me nonetheless . . .

Background:
I have 9 Apollo II units, 3 of which are full node units, and 6 of which are standard units. Of the 3 full node units, I've attached 2 standard hashing units to each of the full node units. That makes 9 total. I've been running one full node unit as a SOLO node with 2 standard hashing units attached with no problems. The other two full node units with 2 attached hashing units each have been running on an "outside pool" with no problems. However, I decided to change things up and now here's where I encountered an odd issue . . . stay with me . . .

Issue:
I decided to point all of my Apollo II units to my single Apollo SOLO node and keep some other non-Apollo equipment on pool mining. BTW, everything in on LAN network, including all the Apollo's. However, when I enter the IP address (192.xxx.x.x:3333 & Username: ) of the Solo Node unit into the Apollo II units that I previously had pool mining I get an error stating "invalid pool url" as if the IP entry is of the wrong nomenclature. I noticed there is no delay in the error as if the IP address was never even considered and more like an IP address can't be accepted from one Apollo to another in the interface field. So, just for fun I tested out several of my non-Apollo units and pointed them to the same Apollo SOLO node without issue using just the IP and wallet address. I also reverse tested the other 2 Apollo II full node units to act as the single SOLO node and the exact same problem occurs with the other Apollos when using just an IP and wallet address. However, I did find a workaround (I think) but that still leaves me with more questions than answers . . .

Workaround:
I eventually tried using "stratum+tcp://192.xxx.x.x:3333" in the required pool url field for the other 2 sets (2x node & 4 standard) of the Apollo II units even though all these units are on the LAN network. And it seems to work. What gives? Another FYI, I'm using headless connections via browsers - if that makes any difference. Anyway, I've never had to enter "stratum+tcp://..." on any non-Apollo units on my network to get the Apollo II SOLO NODE to recognize them, so this is confusing as it only occurs between Apollos. Any thoughts?

Lastly:
All the Apollo II units now show up as a "total" of 9 workers using the "stratum+tcp://192.xxx.x.x:3333" in the pool url field but they are not listed under the "SOLO Mining Users" category on the actual SOLO node miner even though they have ".workername" appended to the BC address. Only the combined hashboards from the solo unit are displayed. Thoughts?

Closing:
I am on v2.0.5 on all node machines. I am using headless w/browsers. All 3 nodes machines have good & high quality 16GB MicroSD cards and up-to-date 2TB NVME node cards. So, all's good under the hood there. Thoughts? Maybe a bug?

Cheers!

Thank you,I have apollo 2 solo mining any pointers as per which solo pool to use? the setup start guide never mentioned there is a solo mine pool ?
the nunchuk satscard that came with the apollo 2 do I input the receive address in wallet UI in apollo 2 dashboard?

First, have you checked your log file.  you got a long way at 700K blocks. Your node may be stuck in a loop trying to confirm and looping through the last 100 to 200 blocks.  It shows in the log.
I had similar issues and thought the same.  The pcie is probably good, but you need a backup card anyway. 

before using a new memory card You need to format the card.  I had issues with the microsd card and I also think the connections in the microsd card slot were not the cleanest.  I would eject and insert the microsd card which would sometimes fix the problem.  I got rid of the supplied microsd card and purchased a new microsd card and flashed it and the system has been much more stable than the original 16gb microsd I flashed several times.  New card is much faster and has more memory(not that important).

Remember, a fresh flashed microsd card will format the pcie drive on first boot.

When you get up to 50%  it does slow down a lot.  Change in block structure.  Have you checked your debug.log file on the bitcoin directory of the pcie drive?  it updates all the time as the node is running.  I would open and view the changes in the log at the end of the file.  That will tell you if the IBD is downloading and processing.
open an executable window  -- "cd /media/pcie/Bitcoin"  then "cat debug.log" will list the file and you can see and scroll through the last lines in the code which is a little faster than opening the editor.
 
Other optional node settings to adjust cache size would use more memory, can help the IBD and which can cause bitcoind crashes which will occur when you run out of available ram memory. bitcoind is supposed to automatically adjust to the computers available memory as the blockchain downloads.  I always check the status of the log.  Did you get an error or did it just drop off.  IF it just drops off, then you can just restart the node and it should continue.  Even with error messages, restarting the node can sometimes fix and get by the error.  I keep all the keyboard HDMI windows closed and rely on remote access which uses less memory.  Having the GUI opened in the browser consumed more system memory.  I would keep the system monitor open so I could see the memory and cpu use.  Raspberry Pi cpus are not fast on IBD.

Backup power supply.  This system is very sensitive to electrical noise/surges.  This can knock the raspberry pi offline and crash the bitcoind program.  Any system crash can corrupt the database memory and then the simplest solution is to reformat the drive and start over.  This would happen if you cant get past a node error in the debug log after multiple node restarts.  Stopping the node and then restarting can also possibly fix issues, but you must make sure to wait for the node to stop and start by viewing the log.  It will show you when shutdown is complete.   Opening the log in an editor will sometimes alert you when the file has updated with new data as the log is written. Thus a backup pcie drive I what I go and copied the main drive with USB adapter.

I have a new Apollo BTC 2 unit I have added to my stable to compliment two Apollo BTC and one other Apollo BTC 2. This new one is proving to be a challenge to get running smoothly. It mines fine, but will not complete the initial blockchain sync. Twice it ran pretty quickly until 48% of the SSD was remaining as free space.  I formatted the SSD both times it got 'stuck' and the second time I tried a new SD Card with a fresh image. Each time it had errors that increased in frequency with each attempt (timeout, connection refused, etc.) but I could restart the Node from the GUI, restart the unit, or sometimes had to power off and power on to recover. The third attempt to sync the blockchain took four days to get to the 48% disk space free and once again has stopped. The unit is now stable and not throwing out any error messages, but had not made any sync progress in the past 3 1/2 days, Still stuck with the current block of 770,203 (since Sunday morning).

At this point I suspect I have a bad SSD. All appears fine in Apollo Web OS. Show as a 1 tb drive. I have ordered a new SSD to try soon in a few days when it arrives.

Any other suggestions from anyone on what to try next would be welcomed. If it is not the SSD, then I am stumped, and reaching out to support directly has not been helpful.

That's normal behaviour. It's for any other miners you have if you want to mine through your solo pool, that's the address you use.

For example I've got my Apollo 2 solo mining but I also have a BitaxeGamma and I've got that pointed at my Apollo 2 via the same address (obviously different IP that reflects my network)

Good day pplz my solo mine dashboard is stating ( Point any Bitcoin Miner on your local network to your Solo Pool with the following URL: 192.168.1.237:3333 Username: ) ??  SOS any help is greatly appreciated I am lost.

Cool, thank you. Before picking up a USB / pcie adapter I'm trying a cache size increase. That seems to be the size error I keep hitting.

Thanks, step in the right direction. I was able to unzip and get the .img file. The flash instructions say "Do not decompress, open, or touch the downloaded image file in anyway. It needs to be flashed in the state you downloaded it."   I took this as don't unzip either.

In Mac disk utility I can erase and reformat the sd, the sd format setting I use is Mac OS Extended (Journaled). I noticed when I initially erased/reformatted the original 16gb sd an additional option was there (Scheme: Master Boot Record), but I no longer see this Scheme option in Disk utility. The partition option is greyed out as well so I can erase/reformat but not partition it.

New error message from etcher

**
failedTarget

Target
Generic Flash-Disk Media

Location
/dev/disk4

Error
EPERM: operation not permitted, open /dev/rdisk4'

---

Found this is a permissions issue. On Mac go into settings, privacy, allow etcher access to removable volumes. Flashing now with a 32gb sd.

---

Apollo II is back up running. Great that I can access miner/node via Ethernet, but when I plug in HDMI the screen stays black. Verified cable and screen work, any known issue with HDMI port or anything I can try to access computer?

apollo-2-mcu2_040624.img.xz is a zipped file. You should unpack it( Use 7-zip) and use balena etcher to flash  the unpacked file ( apollo-2-mcu2_040624.img)  This is after you recreate the disk partition and format the SD card.

I tried a few of the suggestions, erase/reformat the original card as well as trying a new sd card. Still the same error shows. I even downloaded the new etcher version to compare the errors and my issue is a different error message.  I have tried to download the mcu2 image ((apollo-2-mcu2_040624.img.xz) from multiple browsers, same result unfortunately. I ran checksum and I get the correct string too! Etcher won't let me copy paste but below is the top 25% of the scrolling error message. Thanks for the replies, stuck for now.

Edit: After reading the error message back a few times it states a possible corrupted archive but also the source is skipping the application. Maybe something with permissions on the Mac? Going to explore that route for now since I think the checksum shows download is fine.

**
Attention-Something went wrong. If it is a compressed image, please check that the archive is not corrupted. Can't configure or trim a source that is not randomly readable, skipping
/Applications/balenaEtcher.app/Contents/Resources/app/generated/child-writer.js:1

(()=>{var_webpack_modules__=[,
(_unused_webpack_module,exports,webpack_require__)=>
{"use
strict";Object.defineProperty(exports,"__esModule",
{value:true});const
tslib_1=_webpack_require_(2);tslib_1._exportStar(__webpack_require_(3),exports);tslib_1._exportStar(__webpack_require__(114),exports);tslib_1.__.......etc
(_unused_webpack_module,webpack_exports_,-
{"use
strict";_webpack_require_r_webpack_exports__);
_assign:=>__assign,asyncDelegator:
(→_asyncDelegator,_asyncGenerator:
(=>__asyncGenerator,__asyncValues:
**

You need to format the new 2TB drive with the format command in settings. Don't format your old data drive.  Just to make sure all is good.   I did that with my new drive.  Then if you have a usb to pcie adapter, copy your 1TB drive to your new 2TB drive.  takes about 45 mins.  then shutdown, swap and reboot and it should work fine.  THat's my experience.  Keep the 1TB as a backup.  That's what I have.

I did the reindex-chainstate , took longer.  I found it to slow down the process on the raspberry pi. The raspberry cpu isn't fast enough for reindex-chainstate.  Also lack of ram slows the process.    Seems to actually be quicker to start an IBD after a formatted drive and it is quicker.  However, I highly recommend a backup like above.  Once my IBD was complete I copied the drive for a backup.  I also would backup the nvme drive mid IBD download when I was having problems with the raspberry pi crashing mid download.  That made recovery quicker in future crashes.  My hardest part was the IBD.  Once done my system is now running much better.  

I have low trust in the reliability of the included microsd card.  The original is possibly a much older 16GB microsd.   I purchased a new one cheap and with much higher bandwidth and more memory, Cheapest one I could find.  I flashed it and find it more stable than the included card was.

Hi fellow Apollo node-runners. Long time follower here with a first time question, possibly on this issue above.

Updating my Apollo BTC MCU2 unit to a 2TB nvme, and also updating to 2.0.5.

Node stops sync and refuses connection, alerting disk space full. Log shown below.

The nvme drive isn't showing up when checking lsblk in command line, but the drive is functioning when the node connects, at least initially.

The -reindex command will allow node to reconnect. And also re-flashed, confirming checksum. But it will refuse connection shortly after all of this.

Would -reindex-chainstate command make a difference here? Maybe the micro SD is damaged in some way?

Please advise if anything looks familiar.

Shows 2.0.5 for me after the update as well

I tried forcing the update manually, but the version in the GUI seems to remain at 2.0.5.

The update log also shows it as v2.0.5 to v2.0.5.


Is there a way to check the Apollo OS version from the command line?