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

I've got a batch 4 (1x full node + 2x standard nodes), it eventually sync'd and is running fine, however I only see two hashboards on the miner tab, so was wondering if it was possible to use all 3x units as miners and if so, how do you configured such things?

I'm having two separate issues with my Apollo Node (Full + Standard) affecting its continued operation:
(1) The unit randomly stops working while maintaining power and the appearance of hashing activity.  The miners remain on with the fans running, but the unit does not "wake up" when the mouse or keyboard are manipulated and there is no output from the video (HDMI) port to my monitor.  I have tried all possible layer 1 manipulations to wake the machine, but my mining pool shows a reported hashrate of 0, and the only way to regain control of the system is a hard shutdown and restart.  This wastes both my time and my power at a premium.

(2) My machine is randomly dropping off the network with a syslog error reporting a failed handshake and stating my device has the WRONG KEY.  However, the password has not changed since Ive owned the Apollo and it is the only one on my network to drop its LAN connection in this manner.  Unfortunately, I don't know what (if anything) the following log dump is telling me, due to my limited, but anyone venture a guess as to why my LAN connection keeps dropping or how I might fix it?  
Mar 18 18:55:44 futurebitbtc wpa_supplicant[1558]: wlan0: Trying to associate with **:**:**:**:**:** (SSID='*****WiFi' freq=5200 MHz)
Mar 18 18:55:44 futurebitbtc wpa_supplicant[1558]: wlan0: CTRL-EVENT-ASSOC-REJECT bssid=**:**:**:**:**:** status_code=1
Mar 18 18:55:45 futurebitbtc kernel: [2534781.191339] unisoc_wifi unisoc_wifi wlan0: sprdwl_report_connection sm_state (5), status: (2)!
Mar 18 18:55:45 futurebitbtc kernel: [2534781.191399] unisoc_wifi unisoc_wifi wlan0: sprdwl_report_connection *****WiFi failed status code:1!
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]:  [1679180145.0030] device (wlan0): supplicant interface state: completed -> associating
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]:  [1679180145.0032] device (p2p-dev-wlan0): supplicant management interface state: completed -> associating
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]:  [1679180145.0179] device (wlan0): supplicant interface state: associating -> disconnected
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]:  [1679180145.0181] device (p2p-dev-wlan0): supplicant management interface state: associating -> disconnect>
Mar 18 18:55:45 futurebitbtc gnome-shell[1803871]: An active wireless connection, in infrastructure mode, involves no access point?
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]:  [1679180145.1072] device (wlan0): supplicant interface state: disconnected -> scanning
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]:  [1679180145.1074] device (p2p-dev-wlan0): supplicant management interface state: disconnected -> scanning
Mar 18 18:55:45 futurebitbtc wpa_supplicant[1558]: wlan0: Trying to associate with **:**:**:**:**:** (SSID='*****WiFi' freq=2462 MHz)
Mar 18 18:55:45 futurebitbtc wpa_supplicant[1558]: wlan0: CTRL-EVENT-DISCONNECTED bssid=**:**:**:**:**:** reason=0
Mar 18 18:55:45 futurebitbtc wpa_supplicant[1558]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]:  [1679180145.8560] device (wlan0): supplicant interface state: scanning -> associating
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]:  [1679180145.8563] device (p2p-dev-wlan0): supplicant management interface state: scanning -> associating
Mar 18 18:55:45 futurebitbtc wpa_supplicant[1558]: wlan0: Associated with **:**:**:**:**:**
Mar 18 18:55:45 futurebitbtc wpa_supplicant[1558]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Mar 18 18:55:45 futurebitbtc wpa_supplicant[1558]: nl80211: kernel reports: key not allowed
Mar 18 18:55:45 futurebitbtc wpa_supplicant[1558]: wlan0: WPA: Failed to set PTK to the driver (alg=3 keylen=16 bssid=**:**:**:**:**:**)
Mar 18 18:55:45 futurebitbtc wpa_supplicant[1558]: wlan0: CTRL-EVENT-DISCONNECTED bssid=**:**:**:**:**:** reason=1 locally_generated=1
Mar 18 18:55:45 futurebitbtc wpa_supplicant[1558]: wlan0: WPA: 4-Way Handshake failed - pre-shared key may be incorrect
Mar 18 18:55:45 futurebitbtc wpa_supplicant[1558]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="*****WiFi" auth_failures=1 duration=10 reason=WRONG_KEY
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]:  [1679180145.9110] device (wlan0): supplicant interface state: associating -> disconnected
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]:  [1679180145.9112] device (p2p-dev-wlan0): supplicant management interface state: associating -> disconnect>
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]:  [1679180145.9116] device (wlan0): supplicant interface state: disconnected -> 4-way handshake
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]:  [1679180145.9117] device (p2p-dev-wlan0): supplicant management interface state: disconnected -> 4-way han>
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]:  [1679180145.9139] sup-iface[0xaaab0a17a100,wlan0]: connection disconnected (reason -1)
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]:  [1679180145.9143] device (wlan0): supplicant interface state: 4-way handshake -> disconnected
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]:  [1679180145.9245] device (wlan0): Activation: (wifi) disconnected during association, asking for new key
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]:  [1679180145.9253] device (wlan0): state change: activated -> need-auth (reason 'supplicant-disconnect', sy>
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]:  [1679180145.9261] dhcp4 (wlan0): canceled DHCP transaction
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]:  [1679180145.9263] dhcp4 (wlan0): state changed extended -> done
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]:  [1679180145.9333] manager: NetworkManager state is now CONNECTING
Mar 18 18:55:45 futurebitbtc dbus-daemon[1514]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatche>
Mar 18 18:55:45 futurebitbtc NetworkManager[1515]:  [1679180145.9836] device (p2p-dev-wlan0): supplicant management interface state: 4-way handshake -> discon>
Mar 18 18:55:45 futurebitbtc systemd[1]: Starting Network Manager Script Dispatcher Service...
Mar 18 18:55:46 futurebitbtc NetworkManager[1515]:  [1679180146.0302] device (wlan0): supplicant interface state: disconnected -> inactive
Mar 18 18:55:46 futurebitbtc NetworkManager[1515]:  [1679180146.0304] device (p2p-dev-wlan0): supplicant management interface state: disconnected -> inactive
Mar 18 18:55:46 futurebitbtc dbus-daemon[1514]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Mar 18 18:55:46 futurebitbtc systemd[1]: Started Network Manager Script Dispatcher Service.
Mar 18 18:55:47 futurebitbtc kernel: [2534783.200532] Purging 4202496 bytes
Mar 18 18:55:47 futurebitbtc kernel: [2534783.216659] Purging 4198400 bytes
Mar 18 18:55:47 futurebitbtc kernel: [2534783.222814] Purging 4399104 bytes
Mar 18 18:55:57 futurebitbtc systemd[1]: NetworkManager-dispatcher.service: Succeeded.
Mar 18 18:57:31 futurebitbtc Tor[1780]: Tor has not observed any network activity for the past 107 seconds. Disabling circuit build timeout recording.
Mar 18 18:57:46 futurebitbtc NetworkManager[1515]:  [1679180266.0625] device (wlan0): no secrets: No agents were available for this request.
Mar 18 18:57:46 futurebitbtc NetworkManager[1515]:  [1679180266.0629] device (wlan0): state change: need-auth -> failed (reason 'no-secrets', sys-iface-state:>
Mar 18 18:57:46 futurebitbtc NetworkManager[1515]:  [1679180266.0695] manager: NetworkManager state is now DISCONNECTED
Mar 18 18:57:46 futurebitbtc gnome-shell[1803871]: An active wireless connection, in infrastructure mode, involves no access point?
Mar 18 18:57:46 futurebitbtc NetworkManager[1515]:  [1679180266.0813] device (wlan0): Activation: failed for connection '******WiFi'
Mar 18 18:57:46 futurebitbtc NetworkManager[1515]:  [1679180266.0863] device (wlan0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'm>
Mar 18 18:57:46 futurebitbtc gnome-shell[1803871]: An active wireless connection, in infrastructure mode, involves no access point?
Mar 18 18:57:46 futurebitbtc gnome-shell[1803871]: message repeated 2 times: [ An active wireless connection, in infrastructure mode, involves no access point?]
Mar 18 19:00:01 futurebitbtc CRON[1834468]: (root) CMD (/usr/lib/armbian/armbian-truncate-logs)
Mar 18 19:01:49 futurebitbtc Tor[1780]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 18 19:01:49 futurebitbtc Tor[1780]: Our circuit 0 (id: 127850) died due to an invalid selected path, purpose General-purpose client. This may be a torrc configur>
Mar 18 19:05:01 futurebitbtc CRON[1834483]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Mar 18 19:05:27 futurebitbtc Tor[1780]: Failed to find node for hop #1 of our path. Discarding this circuit.

So do you have a picture of how it should be? I took mine apart to clean it and the filthy grinding fan. I took pictures of everything, but that. Thanks

[Mod note: merged posts]

NVM, I got it like the last guy, lol. I got the tiny fan down to a bee buzz now. It was filthy. At least the temps dropped, too, while mining. Not sure why, but I initially took it apart because it dropped out of service while still running the other two satellites, and no matter what I did, it wouldn't get back online unless I unplugged the other two, the other two kept working though. So I formatted a new flash drive and installed it too. That fricken ribbon cable for the NVME drive, what a pita.

I'm just reporting back that I appreciate the personal help from FutureBit that has transpired between my last post here and today. I've sent back the full Apollo to replace the connectors and PSU. Once it is been returned to me, I will have a full and a standard that should be in good shape. I've read some previous posts sometimes someone is interested in additional units. I would be open to considering selling mine to any interested parties.

Hello,
I wanted to throw out a suggestion.  I am a big fan of the standard units, i love running them on basically whatever machine I have lying around...they are very flexible in that way.  I am also a big fan of Start 9's embassy OS.  I wanted to suggest creating a service on embassy OS that would work in their operating system to click and run any standard units one could have plugged into the computer running embassy OS.  Embassy OS has a suite of applications meant to be run for self-hosting various services (such as bitcoin core, lightning node, but also other things like jellyfin and nextcloud...really anything that a user would want running on a computer 24/7).  So, since that computer with embassy OS will be running 24/7, if I could plug my standard units into my machine running embassy, and open a service in that OS to fire up the miners, point them to the right pool, etc...I think that would be pretty amazing.  Also - I think it could really benefit the futurebit apollo project as there may be many users of embassy OS that would love to buy a futurebit standard miner and try it out with their embassy OS upon release of this cool new service

Anyways, here is their github link: https://github.com/Start9Labs/embassy-os/releases.  They have a pretty active community marketplace, where developers of other projects can create services in the embassy OS ecosystem.  Thanks for your consideration, hopefully this finds the right eyeballs for review. 

Hi. I got a response on Monday to the email I sent that was a reply to my order. I followed the suggestion in that email to do a power cycling of the standard and reboot the main unit. Both units fired up as normal and I thought that resolved the issue. However I noticed a few anomalies after that. At first I wasn't sure if these anomalies were actual problems and so I started to compose an email to you yesterday regarding what I was noticing.  However, then I noticed the connectors to the full unit were hot to touch (on balanced mode, with no node syncing) and upon closer inspection I saw that those connectors had burned out. That appears to be a new issue. I hadn't noticed any problems with the full unit before; I just thought their might be an issue with the power supply to the standard. In any case, I sent you pictures yesterday (reply to the order email thread). Both units are now off, out of commission, for safety, awaiting your response. Thanks.

We respond to all support emails and as far as I can see we dont have any open tickets right now so maybe your email is not going through? FYI all Apollos comes with a standard one year warranty.

I don't have experience with their direct support, but I doubt this is normal. Maybe raise the issue here and quote @jstefanop for support. In regards to power supply: You can actually use any good power PC supply, you just need to bridge two pins on the ATX plug to make it jump-start.
If you need to buy one, I would recommend the most efficient one you can afford. Because this will likely run 24/7, so 80 Plus Gold or better.

The other thing I'm trying to figure out if if there is an alternate power adapter people here have found that works reliably with Apollo? I think that's the source of the issue I'm having and if I don't get support for a warranty replacement I doubt I'd buy another one from Futurebit. I understand it's possible to run 300 W+ adapters with Future Bit and the checking I've done seems to indicate that it's possible to find one that runs quite a bit cooler (say 40 C instead of 60 C) than the one that FutureBit offers, but so far I haven't found one with dual 6 pin connectors. Any suggestions?

I bought direct from futurebit and have tried all the usual support channels (chat, email, replying to my order email etc) over the past week but no response. Wondering is that was to be expected or an anamoly?

If it's a warranty case, check back with your reseller first. He should be able to directly sort that out with you or file a support case on Futurebit side.

Is there one? If so, what is it? I've reached out through multiple direct channels for help with a failed unit < 90 days old and have received no response (yet). Is this typical post sales support?

That sounds promising.

I hope it ends up being published as open source. I bought the Apollo assuming it to have open source software for the mining(like cgminer for example), but was disappointed to realize it only has a closed source binary available to mine with. By the way, I remember you mentioned some time ago that the code could be open if the Apollos did well financially, and I think they have done well based on this thread and they being sold out all the time. Are we getting an open source miner for the Apollos?

... and also most important, no one ever has and probably ever will write transaction bias software for your own node.

GBT 'allowed' it, but over the many years GBT existed, no one ever wrote anything to do it,
not even Luke who used to spout this as a reason to use GBT.

By connect to other servers I mean your node will be highly connected to the major mining pool backbone for faster block propagation. You would still be your own "pool" and mining your own blocks/transactions.

FYI cool functionality we are building out is that solo mining will essentially be your own stratum pool (so the pool will run locally on your device and your hashboard will be connected to that internal pool), but the fun part is that you can use it as your own pool infrastructure, so if you have other miners (even non Apollo hardware) you could point all of them to the Apollo and solo mine.

"Pool in a box"

You mentioned in theory ckpool can censor transactions, wouldn't exactly the same statement apply to the "Apollo Pool" since you said the plan is to connect to other servers?

At the end of the day using any pool you need to trust the person behind it.

You get to learn something new, and - if you are prepared to take the risk - you can save the pool fee if you find a block. Which is up to 2% (as of today, 3300 USD). And in terms of risk, I mainly mean using the Apollo node as mining node from within in your home network. Which has its downsides, as the Apollo node is definitely not as well connected as a pool's mining node, also because your home network will have less uptime stability and lower bandwidth.

Think of it this way ... if you are using an rpi cpu to do all your bitcoin processing ...

... on top of all the issues with getting that one block you might find out to the world wide bitcoin network fast,
and the fact that your bitcoin needs to see all blocks on the world wide network as fast as possible to reduce the amount of time spent working on stale blocks, ...

how fast do you think an rpi can process that one block you find then send it out,
and how fast do think an rpi can see a new network block, process it and send a work change to your miner?

You would be using an rpi cpu to do all that work ... compared to high performance servers used by pools
(though I will admit your choice of pools is a single server hiding somewhere in the usa with no distribution network of it's own - that loses blocks - so rather an odd choice)

Example: (not sure if the orange pi is up to these specs but ...)
Model: Raspberry Pi 4 Model B Rev 1.5
BogoMIPS: 108.00
Cores/Threads: 4
Features: fp asimd evtstrm crc32 cpuid
Ram: 8GB

.. .competing with ...

One of my nodes (not the higher spec master server)
Model: Intel(R) Xeon(R) E-2286G CPU @ 4.00GHz
BogoMIPS: 7999.96
cpu MHz : 4790.301
Cores/Threads: 12
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d
Ram: 32GB

Of course the most useful one there is avx2

... of course my personally modified, performance improved, bitcoin is compiled to use these extra instructions ...

Well someone here solve the last ckpool solo block using 10TH worth of Apollos Probably why the pool has attracted more Apollo users since then.

The benefit is that you are using your own node to construct and broadcast the bitcoin block if found, with ckpool, the pool itself has control over the block creation (and therefor could theoretically censor transactions). Until we release our own implimination of solo mining I would not suggest trying to do this on your own unless you know your node is well connected to other pools (which is hard to do on an individual level). We are working with pool partners to directly connect all Apollo solo miners to major pools once our implementation launches.