Progress update: it’s now synced past the point where the first M.2 died consistently, and still truckin’. I guess it was a flaky M.2??

Welp, progress.

After buying TWO of those Crucial P3 devices and having the exact same symptom (dead on boot, nothing coming out of the HDMI port??) I bought a Crucial *P2* M.2 and it booted up just fine! I formatted it and it's now syncing. Fingers are crossed...

Thank you for your help!

I was willing to give it a try for $42, but the device came and my system won't even boot with it installed. It boots with the older M.2 just fine.

I'm under the impression that all that is required is that I take out the old (working) M.2, replace it with the new one, then boot it up... I believe this is the procedure I followed the last time when I originally upgraded the 500GB M.2 to 1GB. No luck though.

Anyone know what might be going on here? The device is powered up but won't ask for an address using DHCP.

Hi everyone, I have an issue with my gen 1 Apollo BTC. The node cannot seem to sync past ~459,000 blocks... the node stops (crashes?), and when I restart it it will pick up at around block ~458,000 and die again a short time later. Note that because this was a Gen1 device, I did swap out the M.1 for a 1T device at some point in the past. This node has NEVER synced through to completion. I've been mining on it successfully since I got it, as one of the early adopters from Futurebit.

What I've tried so far:
1. Reformatting the flash
2. Stopping the miner to give more breathing room (temperature) to the node
3. Restarting the node when it stalls

Nothing has worked so far. Please pardon me if this has already been discussed in this thread, but I didn't find it when searching this site nor have I gone through all 100+ pages to review all of the posts.

Any help is appreciated!

I'm also having this issue. It started after the upgrade to 0.3.1 (but not immediately after; I was running on 0.3.1 for some time before the issue manifested itself). It hasn't righted itself after several power cycles. The miner is still attached to the pool and hashing, but the local web UI shows no data whatsoever.

I fired up my Apollo-BTC the other day and noticed that it's sending out a DNS query every five seconds for raw.githubusercontent.com.

Any insight into what it's after up there?

I have the opposite situation from crypto_curious... I currently run a RPi as the controller for a couple of GekkoScience Terminus R606 miners. Can I run these miners off of Apollo BTC instead, and decommission the RPi?

Looking forward to getting my Apollo BTC soon!!!

Sure enough, once it got within about 500 blocks of the head of the chain I started to see inbound connections. Another Apollo node checking in!!

Hm, thinking about this some more... is having my node be fully synchronized to the blockchain a precondition for getting inbound connections? It's not quite there yet. Maybe I'm just impatient!

Hi everyone,

I've just upgraded both of my Apollos (a batch 1 and a batch 2) to the new firmware, replaced MCU on the batch 1, etc. They're both on different networks, and the batch 2 appears to be humming along nicely.

The batch 1 is having a few issues.

1. The MCU temp seems pretty high. It's at about 81C. Is this a concern?
2. My ssh connection to the node is very unstable. It appears as though this may be related to memory(?) since the connection doesn't have as many issues during startup/shutdown. But during steady state my ssh connections either hang and never authenticate, or I authenticate and get disconnected shortly thereafter. Perhaps it's due to litecoind performing its initial synchronization to the blockchain and this will fix itself once it's caught up. I'll keep an eye on it. The web UI doesn't appear to be affected negatively and the Apollo is mining succesfully, so this is an annoyance but not necessarily a problem.
3. I'm not getting any inbound connections to my node.

Regarding the last point: my network is... different. I have the node sitting behind an edge router that ultimately breaks out into two load balanced WAN connections. How does litecoind know which public IP address to advertise to the world for getting inbound connections? Is it using some kind of STUN technique? I've coerced all outbound connections using TCP/9333 out of one specific WAN interface, but I'm not seeing anything come inbound. While my routers don't support UPnP (and even if they did I'd have disabled it ;-) I have confirmed that my port forwarding rules work fine.

Any tips on how to make sure the world sees the correct WAN IP are appreciated!

Thanks for the reply. If it happens again, I'll let it sit until I get to lay eyes on it myself. I just re-flashed it recently to 1.1, so I'm less inclined to think it's the SD card. We'll see if it happens again, and I'll report back.

Hi everyone. I had a nice long run with my Apollo on 1.0, with few to no issues. About a month ago I moved it to a new location which I visit once a week or so, and upgraded it to 1.1. Since then, on two occasions it has stopped mining. Because this is a remote site, I put an IP-enabled power switch at the location so I could remotely power cycle equipment at the site. Unfortunately, my Apollo is connected to an HP server power supply with a breakout board, which requires me to *also* physically press a button to turn power back on.

Anyhow, on the first occasion I tried power cycling the IP-enabled power switch, forgetting that the breakout board meant that I couldn't get the system restarted. So I don't have much diagnosis to go on. But on the second occasion when it stopped mining, I happened to be at the remote site. Before power cycling it, I could not get into the Apollo at all -- it wouldn't respond to SSH, ping, etc. It was down hard. I can presume, but cannot confirm, that the first lockup was similar.

I've since rebooted it and it is now mining successfully again. Is there anything I can look at -- log files, journal, etc. -- that may help diagnose what caused it to lock up? I had several months of successful running on 1.0 with no issues, and now two lockups on 1.1 within a month. (It may be mere coincidence, I'm just pointing it out.)

I'd like to get to the bottom of it, since I won't have the ability to remotely power cycle this thing except on weekends... until my Futurebit PSU shows up :-)

Nailed it. I had it on a subnet that allowed it access to other devices on my LAN, but no route to the internet. It's mining away happily now, thanks!!!

I just got my Apollo unboxed and set up, and am running into an error after configuring the miner, it says its unable to connect to port 4028 (which I gather is the stats API port for bfgminer). The dashboard is blank except for the ECONNREFUSED error. The bfgminer process does appear to be running, however.

Here’s some syslog output:

Dec 22 01:41:52 futurebit systemd[1]: serial-getty@ttyS0.service: Service hold-off time over, scheduling restart.
Dec 22 01:41:52 futurebit systemd[1]: Stopped Serial Getty on ttyS0.
Dec 22 01:41:52 futurebit systemd[1]: Started Serial Getty on ttyS0.
Dec 22 01:41:53 futurebit node[1334]: {"name":"app","hostname":"futurebit","pid":1334,"cid":"d67a259f-e1e1-47e6-8c11-414e8e339260","seq":0,"method":"api/miner/online","stack":[{"cid":"d67a259f-e1e1-47e6-8c11-414e8e339260","seq":0,"method":"api/miner/online"}],"level":30,"user":{"iat":1545442681,"aud":"auth","sub":"apollouser"},"source":"auto","when":"before","msg":"before_api/miner/online","time":"2018-12-22T01:41:53.740Z","v":0}
Dec 22 01:41:53 futurebit node[1334]: {"name":"app","hostname":"futurebit","pid":1334,"cid":"f1878d82-d81e-4542-b3a6-956078948c12","seq":0,"method":"api/miner/stats","stack":[{"cid":"f1878d82-d81e-4542-b3a6-956078948c12","seq":0,"method":"api/miner/stats"}],"level":30,"user":{"iat":1545442681,"aud":"auth","sub":"apollouser"},"source":"auto","when":"before","msg":"before_api/miner/stats","time":"2018-12-22T01:41:53.790Z","v":0}
Dec 22 01:41:53 futurebit node[1334]: {"name":"app","hostname":"futurebit","pid":1334,"cid":"f1878d82-d81e-4542-b3a6-956078948c12","seq":0,"method":"api/miner/stats","stack":[{"cid":"f1878d82-d81e-4542-b3a6-956078948c12","seq":0,"method":"api/miner/stats"}],"level":50,"user":{"iat":1545442681,"aud":"auth","sub":"apollouser"},"source":"auto","when":"after","err":{"message":"Error: connect ECONNREFUSED 127.0.0.1:4028","name":"InternalError","stack":"InternalError: Error: connect ECONNREFUSED 127.0.0.1:4028\n    at Socket.client.socket.on (/opt/apolloapi/src/store/api/miner/minerStats.js:70:7)\n    at Socket.emit (events.js:180:13)\n    at emitErrorNT (internal/streams/destroy.js:64:\n    at process._tickCallback (internal/process/next_tick.js:114:19)"},"ms":7,"originalErr":null,"errInfo":{"type":"internal","severity":"error","message":"Error: connect ECONNREFUSED 127.0.0.1:4028","reasons":[{"path":"stats","message":"ECONNREFUSED"}],"data":null},"msg":"after_api/miner/stats (7ms)","time":"2018-12-22T01:41:53.798Z","v":0}

If anyone has any recommendations for a power supply for the Apollo I’m all ears. I have an L3+ running on an APW3++, can I use the extra connector? Or am I better off picking up a stand-alone supply? For me noise is not a concern, I’d prefer clean power and reliability over a quiet build if that helps narrow down the choices.

Thanks in advance!

Multicast DNS (mDNS) is generally what resolves hostnames with the .local TLD. I suspect that whoever "claims" futurebit.local first will win. You'll probably need to go into the device and change its hostname to something else, so that the fresh device can claim "futurebit.local" when it comes up for the first time.

Thanks for the info! The first two firmwares on Bitmain's page are really old. The last one is new, but looks... "different." Like it was posted there as an afterthought. I was leery of trying it for that reason.

Meanwhile, the OpenWRT group produces new builds for the Antrouter platform constantly. Including the latest (18.06) trunk. This would presumably allow me to use the latest packages for things that aren't necessarily Antrouter-specific, like running routing protocols or other Linux-y things. If I decide to cross my fingers and take the chance to update, I'll report back. I was just hoping to hear some success stories from someone that's ahead of me on this journey :-)

Hi everyone. I just picked up an R1-LTC Antrouter and am having fun playing around with it. The firmware that came stock on it is really old (based on OpenWRT Barrier_Breaker). There are newer OpenWRT trunks, even ones that support Antrouters specifically... but they only call out "R1" as the model number:

https://openwrt.org/toh/hwdata/bitmain/bitmain_antrouter_r1

I'd love to upgrade the firmware to something newer; Barrier Breaker is so old it's a challenge to upgrade/install newer packages. Has anyone on this board tried upgrading to a newer OpenWRT -- not something downloaded straight from Bitmain?

It is, in fact, possible to mine over wifi. I picked one of these little guys up yesterday and all it takes is just a little configuration to get it to do what you want.

Under the hood this thing runs OpenWRT, and there are lots of walkthroughs online for connecting to wifi networks as a client. The basic gist is to
use the GUI to scan for existing wifi networks, and click "Join". This will create a new WWAN network. You want this to be in the WAN firewall zone. (These routers have two zones, LAN and WAN, which govern how traffic flows and gets NATted.) Then you want to disable the existing WAN interface, which defaults to the physical port eth1. Last, modify the LAN interface to bind to eth0 and set up DHCP.

Back up your configuration before starting Also note that once you commit these changes, if you did it incorrectly you may wind up cutting yourself off from all access.

If you run into any issues I can try to help.