Ultra Under-overclock image for A2 Innosilicon by Emdje - V5.0

[CartmanSPC]

First of all...so sorry about asking in this thread but thought it would be the best place where people would know.

I noticed an interesting distinction between the A2 and A2 Mega in regard to the power connectors the blades use and wanted to confirm with others.

The regular A2 (the one Emdje's old image works with) appears to have an Eight-Pin +12 V CPU Power Connectors on the blades. This means that +12v is on the top or clip side.

Example:


I realized this from the picture earlier in this thread:


Can someone confirm? I think it is fairly obvious but wanted to make sure. If this is the case then a standard PCI-E connector will not work as that has the +12 V on the bottom or opposite the clip side:



This is different than the A2 Mega. The A2 Mega comes with standard PCI-E connectors on the blades. I found it strange that the power supply provided with my A2 Mega had exactly six Eight-Pin +12 V CPU Power Connectors with cable lengths perfectly spaced for the location of the blades but were FORCE in to fit the PCI-E connector....now it makes sense. The power supply was build for the original A2 and they forced it to work with the A2 Mega.

Here is a picture of an A2 Mega with PCI-E connectors and the Eight-Pin +12 V CPU Power cables forced into them:


I guess it is important to know that +12 V on the original A2 (blue PCB) is on the top of the connector but +12 V on the A2 Mega (green PCB) is on the bottom? What would happen if they were reversed (if someone plugged in a PCI-E cable into the A2)? You can't physically plug in an 8-pin PCI-E cable into an Eight-Pin +12 V CPU Power Connector but a 6-pin PCI-E cable would fit.

I realized all this while working on replacing the PS in my A2....decided to delay until I get my voltmeter from work to verify.

[emdje]

Can someone confirm? I think it is fairly obvious but wanted to make sure. If this is the case then a standard PCI-E connector will not work as that has the +12 V on the bottom or opposite the clip side:

I can confirm. When I changed out the power supply for a BeQuite one, I had to cut the cable somewhere and connect the plus to the minus and vice versa. I have an 'old' A2 with 8 chips (two blade version)
If that is different on the A2 mega's I don't know.

[emdje]

Why can not I run the image? I do not see it on the network. My raspberry Pi work good.

Do the green lights on the blade stop flashing after a while or do they continue? If they stop flashing it means the blades started to hash.
I don't know how you connected your blade to your network, but it might be the IP address is changed. With new versions of the software that sometimes happens with me too. I just login to the modem and see what devices are connected and find the IP like that.
If not try to hock up a monitor and find it using the command line:
https://learn.adafruit.com/adafruits-raspberry-pi-lesson-3-network-setup/finding-your-pis-ip-address

[mjgraham]

As far as power it you did hook it up backwards and the psu did turn on you'd have a lot of broken stuff, like it is at the least you will have a +5 to gnd short back through the communication cable. After finally getting a complete A2 unit I have found that the engineering is just enough to get by, if you notice it is on a 8 pin header but with a 6 pin connector , probably had millions of them in stock, I just soldered screw terminals into the empty header . I have found that these units are quite annoying to keep running so far, board resets all the time , I guess time to overvolt..

EDIT

I do know the blue boards like emdje has the power is reversed I can verify that for sure

[coinflow]

Is it possible to update a miner with your image simply via apt-get update/upgrade, once it is installed and running?
What version of glibc is in use? See here: http://arstechnica.com/security/2016/02/extremely-severe-bug-leaves-dizzying-number-of-apps-and-devices-vulnerable/

[ZeroGee]

Hello, I am trying to use the new 5.0 for a2 mega (i think, bought second hand on ebay) and it starts, and then slowly dies.... i am trying to run it at super low level, 700mhz to see if the hw errors go away.. but to no avail.

starts fine after power-on boot,

Code:

[2016-02-03 05:18:02] Started cgminer 3.9.0
 [2016-02-03 05:18:02] Run Reset=1
 [2016-02-03 05:18:02] ST MCU hardware reset start
 [2016-02-03 05:18:06] SPI Speed 4000 kHz
 [2016-02-03 05:18:06] ST MCU - Enable (Pre-header)
 [2016-02-03 05:18:06] A2 = 700,24
 [2016-02-03 05:18:06] A2 PLL Clock = 700MHz
 [2016-02-03 05:18:06] A2 = 700,24
 [2016-02-03 05:18:06] A2 PLL Clock = 700MHz
 [2016-02-03 05:18:06] A2 = 700,24
 [2016-02-03 05:18:06] A2 PLL Clock = 700MHz
 [2016-02-03 05:18:06] A2 = 700,24
 [2016-02-03 05:18:06] A2 PLL Clock = 700MHz
 [2016-02-03 05:18:06] A2 = 700,24
 [2016-02-03 05:18:06] A2 PLL Clock = 700MHz
 [2016-02-03 05:18:06] A2 = 700,24
 [2016-02-03 05:18:06] A2 PLL Clock = 700MHz
 [2016-02-03 05:18:06] AUTO GPIO CS
 [2016-02-03 05:18:07] spidev0.0(cs0): Found 12 A2 chips
 [2016-02-03 05:18:07] Found chip 1 with 54 active cores
 [2016-02-03 05:18:07] Found chip 2 with 54 active cores
 [2016-02-03 05:18:07] Found chip 3 with 54 active cores
 [2016-02-03 05:18:07] Found chip 4 with 54 active cores
 [2016-02-03 05:18:07] Found chip 5 with 54 active cores
 [2016-02-03 05:18:07] Found chip 6 with 0 active cores
 [2016-02-03 05:18:07] Found chip 7 with 54 active cores
 [2016-02-03 05:18:07] Found chip 8 with 54 active cores
 [2016-02-03 05:18:07] Found chip 9 with 54 active cores
 [2016-02-03 05:18:07] Found chip 10 with 54 active cores
 [2016-02-03 05:18:07] Found chip 11 with 54 active cores
 [2016-02-03 05:18:07] Found chip 12 with 0 active cores
 [2016-02-03 05:18:07] Found 12 chips with total 540 active cores
 [2016-02-03 05:18:08] spidev0.0(cs1): Found 12 A2 chips
 [2016-02-03 05:18:08] Found chip 1 with 54 active cores
 [2016-02-03 05:18:08] Found chip 2 with 54 active cores
 [2016-02-03 05:18:08] Found chip 3 with 54 active cores
 [2016-02-03 05:18:08] Found chip 4 with 54 active cores
 [2016-02-03 05:18:08] Found chip 5 with 54 active cores
 [2016-02-03 05:18:08] Found chip 6 with 0 active cores
 [2016-02-03 05:18:08] Found chip 7 with 54 active cores
 [2016-02-03 05:18:08] Found chip 8 with 54 active cores
 [2016-02-03 05:18:08] Found chip 9 with 54 active cores
 [2016-02-03 05:18:08] Found chip 10 with 54 active cores
 [2016-02-03 05:18:08] Found chip 11 with 54 active cores
 [2016-02-03 05:18:08] Found chip 12 with 0 active cores
 [2016-02-03 05:18:08] Found 12 chips with total 540 active cores
 [2016-02-03 05:18:08] spidev0.0(cs2): Found 12 A2 chips
 [2016-02-03 05:18:08] Found chip 1 with 54 active cores
 [2016-02-03 05:18:08] Found chip 2 with 54 active cores
 [2016-02-03 05:18:08] Found chip 3 with 54 active cores
 [2016-02-03 05:18:08] Found chip 4 with 54 active cores
 [2016-02-03 05:18:08] Found chip 5 with 54 active cores
 [2016-02-03 05:18:08] Found chip 6 with 0 active cores
 [2016-02-03 05:18:08] Found chip 7 with 54 active cores
 [2016-02-03 05:18:08] Found chip 8 with 54 active cores
 [2016-02-03 05:18:08] Found chip 9 with 54 active cores
......etc

then I get a lot of invalid nonce errors...


and then it slowly dies when trying to reset the boards

Code:

[2016-02-03 05:19:32] Failed to reset bc from chip(cs4) 0
 [2016-02-03 05:19:32] Reinit board (cs4)
 [2016-02-03 05:19:32] Accepted 01d1b814 Diff 36K/64 BA1 4 pool 0
 [2016-02-03 05:19:32] Accepted 036af226 Diff 74/64 BA1 1 pool 0
 [2016-02-03 05:19:32] Accepted 037eb80e Diff 73/64 BA1 3 pool 0
 [2016-02-03 05:19:32] Accepted 018460f3 Diff 168/64 BA1 3 pool 0
(5s):64.33M (avg):64.75Mh/s (pool):59.76Mh/s | A:73536  R:0  HW:114  WU:54709.1/m^M [2016-02-03 05:19:32] Accepted 03372d18 Diff 20.4K/15360 BA1 2 pool 0
 [2016-02-03 05:19:33] Failure(cs4)(240): missing ACK for cmd 0x04
 [2016-02-03 05:19:33] ACK(cs4) timeout:cmd_RESET_BCAST-1.14901s
 [2016-02-03 05:19:33] Reinit board failure (cs4)

and when it has tried to reinit the boards, it just sits there..

if I try to restart cgminer manually this is the error:

Code:

[2016-02-03 05:42:45] Started cgminer 3.9.0
 [2016-02-03 05:42:45] Run Reset=1
 [2016-02-03 05:42:45] ST MCU hardware reset start
 [2016-02-03 05:42:49] SPI Speed 4000 kHz
 [2016-02-03 05:42:49] ST MCU - Enable (Pre-header)
 [2016-02-03 05:42:49] A2 = 700,24
 [2016-02-03 05:42:49] A2 PLL Clock = 700MHz
 [2016-02-03 05:42:49] A2 = 700,24
 [2016-02-03 05:42:49] A2 PLL Clock = 700MHz
 [2016-02-03 05:42:49] A2 = 700,24
 [2016-02-03 05:42:49] A2 PLL Clock = 700MHz
 [2016-02-03 05:42:49] A2 = 700,24
 [2016-02-03 05:42:49] A2 PLL Clock = 700MHz
 [2016-02-03 05:42:49] A2 = 700,24
 [2016-02-03 05:42:49] A2 PLL Clock = 700MHz
 [2016-02-03 05:42:49] A2 = 700,24
 [2016-02-03 05:42:49] A2 PLL Clock = 700MHz
 [2016-02-03 05:42:49] AUTO GPIO CS
 [2016-02-03 05:42:50] Failure(cs0)(20): missing ACK for cmd 0x04
 [2016-02-03 05:42:50] ACK(cs0) timeout:cmd_RESET_BCAST-1.2750s
 [2016-02-03 05:42:51] Failure(cs1)(20): missing ACK for cmd 0x04
 [2016-02-03 05:42:51] ACK(cs1) timeout:cmd_RESET_BCAST-1.3020s
 [2016-02-03 05:42:52] Failure(cs2)(20): missing ACK for cmd 0x04
 [2016-02-03 05:42:52] ACK(cs2) timeout:cmd_RESET_BCAST-1.2607s
 [2016-02-03 05:42:53] Failure(cs3)(20): missing ACK for cmd 0x04
 [2016-02-03 05:42:53] ACK(cs3) timeout:cmd_RESET_BCAST-1.4347s
 [2016-02-03 05:42:54] Failure(cs4)(20): missing ACK for cmd 0x04
 [2016-02-03 05:42:54] ACK(cs4) timeout:cmd_RESET_BCAST-1.2680s
 [2016-02-03 05:42:55] Failure(cs5)(20): missing ACK for cmd 0x04
 [2016-02-03 05:42:55] ACK(cs5) timeout:cmd_RESET_BCAST-1.2720s
 [2016-02-03 05:42:55] No any A2 board

No any A2 board

any ideas?

I'd be blaming the power supply. Disconnect say half of the boards from power and see if it becomes stable. The PSU in mine could not handle more than 4 at 1200MHz, and only 5 at 700MHz. I just strapped a second power supply to mine, each powering 3 boards at 1320MHz.

[emdje]

Is it possible to update a miner with your image simply via apt-get update/upgrade, once it is installed and running?
What version of glibc is in use? See here: http://arstechnica.com/security/2016/02/extremely-severe-bug-leaves-dizzying-number-of-apps-and-devices-vulnerable/

No that is not possible, and I don't know which version of glibc is used I would have to check that when I have some more time.

[emdje]

I'd be blaming the power supply. Disconnect say half of the boards from power and see if it becomes stable. The PSU in mine could not handle more than 4 at 1200MHz, and only 5 at 700MHz. I just strapped a second power supply to mine, each powering 3 boards at 1320MHz.

That is very well possible, my blade is using about 200 watts for the one 8 chip blade (218W in total). But running at 700MHz would draw about 115W per blade * 6 = 690W + fans so lets say 750W for the power supply. If it is a bad one it might cause it to be unstable.
(Running your rig overvolted at 1440 MHz it would draw 1500+Watts and doing ~132MH/s) <-- I do not recommend btw because of the power draw and the heat it produces, 1 blade like I have you can cool very well.

[mjgraham]

Does anyone have any idea what the LEDs on the boards represent? been trying to repair some boards and they all have some variation of the LEDs . I had one board that had an incorrect feedback resistor in circuit was running about 0.7v, just one one pair of A2s. Seems to be either people work on things with hammers or I guess they get dropped a lot. Lots of sheared off components. Anyone else work on these boards and have any stories?

Looking at them now after testing I guess they relate some how to the number of chips found, maybe a binary count to a point even though when I bypass some it kinds of relates to that. Something else that is odd if I bypass any of the chips on the left chain I don't get any communication, I can do them on the right. Also the left chain seems to have a 3Mhz SPI bus and the right only has a 1.5 Mhz bus. Anyway just some more observations

[coinflow]

Is it possible to update a miner with your image simply via apt-get update/upgrade, once it is installed and running?
What version of glibc is in use? See here: http://arstechnica.com/security/2016/02/extremely-severe-bug-leaves-dizzying-number-of-apps-and-devices-vulnerable/

No that is not possible, and I don't know which version of glibc is used I would have to check that when I have some more time.

I'd recommend to check that as soon as possible. Since it is a really severe thing.

[mjgraham]

Is it possible to update a miner with your image simply via apt-get update/upgrade, once it is installed and running?
What version of glibc is in use? See here: http://arstechnica.com/security/2016/02/extremely-severe-bug-leaves-dizzying-number-of-apps-and-devices-vulnerable/

No that is not possible, and I don't know which version of glibc is used I would have to check that when I have some more time.

I'd recommend to check that as soon as possible. Since it is a really severe thing.

ldd --version gives me
ldd (Debian EGLIBC 2.13-38+rpi2) 2.13

while it is a big deal I am not sure how bad in this case it is, I mean it has been around since 2008 , been out for 7 months already, if these were right on the internet w/o a firewall maybe I would be worried, I am up for some scenarios to talk about 

[psycodad]

Is it possible to update a miner with your image simply via apt-get update/upgrade, once it is installed and running?
What version of glibc is in use? See here: http://arstechnica.com/security/2016/02/extremely-severe-bug-leaves-dizzying-number-of-apps-and-devices-vulnerable/

No that is not possible, and I don't know which version of glibc is used I would have to check that when I have some more time.

I'd recommend to check that as soon as possible. Since it is a really severe thing.

ldd --version gives me
ldd (Debian EGLIBC 2.13-38+rpi2) 2.13

while it is a big deal I am not sure how bad in this case it is, I mean it has been around since 2008 , been out for 7 months already, if these were right on the internet w/o a firewall maybe I would be worried, I am up for some scenarios to talk about 

In my understanding it means that if the application compiled against the vulnerable glibc does a gethostbyname() call it can be owned. Now since a miner typically resolves the IP of the pool it wants to connect to, the miner might be pretty easy to attack as you can relatively easy predict that it will resolve its pool sooner or later. It is unclear to my understanding if the DNS server your miner uses would discard an actual malformed answer that would trigger the vulnerability.

The firewall you have in front of your miners doesn't help anything here (except you have it locked down so much, that the miner only can connect to the pools ip and port, else the attacker just launches a reverse shell with nc or whatever is en vogue right now.
So theoretically you could just remove any DNS servers from your Pi (echo "" > /etc/resolv.conf) and instead of the name of your pool, add the IP of the pool in the web frontend (and hope your pool doesn't switch providers or whatever could make a change of IP necessary).

Other than that running "apt-get update; apt-get upgrade" and waiting for a new miner binary to be released there is not much we Terminator operators can do right now. Let's hope this will be before real exploits are being published. AFAIK there are currently only 2 PoC exploits in the wild which make it unlikely that the the average Terminator out there is targeted but that might change quickly once there is for example a module for metasploit.

[mjgraham]

In my understanding it means that if the application compiled against the vulnerable glibc does a gethostbyname() call it can be owned. Now since a miner typically resolves the IP of the pool it wants to connect to, the miner might be pretty easy to attack as you can relatively easy predict that it will resolve its pool sooner or later. It is unclear to my understanding if the DNS server your miner uses would discard an actual malformed answer that would trigger the vulnerability.

The firewall you have in front of your miners doesn't help anything here (except you have it locked down so much, that the miner only can connect to the pools ip and port, else the attacker just launches a reverse shell with nc or whatever is en vogue right now.
So theoretically you could just remove any DNS servers from your Pi (echo "" > /etc/resolv.conf) and instead of the name of your pool, add the IP of the pool in the web frontend (and hope your pool doesn't switch providers or whatever could make a change of IP necessary).

Other than that running "apt-get update; apt-get upgrade" and waiting for a new miner binary to be released there is not much we Terminator operators can do right now. Let's hope this will be before real exploits are being published. AFAIK there are currently only 2 PoC exploits in the wild which make it unlikely that the the average Terminator out there is targeted but that might change quickly once there is for example a module for metasploit.

True I can see that, for some reason I had not though about send a download and run type thing.

I was looking, I see the vulnerability for glibc but not really for eglibc, guess going to have to make a test bench somehow

[psycodad]

In my understanding it means that if the application compiled against the vulnerable glibc does a gethostbyname() call it can be owned. Now since a miner typically resolves the IP of the pool it wants to connect to, the miner might be pretty easy to attack as you can relatively easy predict that it will resolve its pool sooner or later. It is unclear to my understanding if the DNS server your miner uses would discard an actual malformed answer that would trigger the vulnerability.

The firewall you have in front of your miners doesn't help anything here (except you have it locked down so much, that the miner only can connect to the pools ip and port, else the attacker just launches a reverse shell with nc or whatever is en vogue right now.
So theoretically you could just remove any DNS servers from your Pi (echo "" > /etc/resolv.conf) and instead of the name of your pool, add the IP of the pool in the web frontend (and hope your pool doesn't switch providers or whatever could make a change of IP necessary).

Other than that running "apt-get update; apt-get upgrade" and waiting for a new miner binary to be released there is not much we Terminator operators can do right now. Let's hope this will be before real exploits are being published. AFAIK there are currently only 2 PoC exploits in the wild which make it unlikely that the the average Terminator out there is targeted but that might change quickly once there is for example a module for metasploit.

True I can see that, for some reason I had not though about send a download and run type thing.

I was looking, I see the vulnerability for glibc but not really for eglibc, guess going to have to make a test bench somehow

eglibc is equally affected from the problem as far as I can judge:

i.e.: http://www.ubuntu.com/usn/usn-2485-1/

[mjgraham]

I have been working on a miner that I suscpected the contrller board died for some reason, I had built a replacement out of a CPLD but it is not the handiest thing to put in place so today I decided to figure this thing out. The device would not find any boards but I tested all of them one at a time and they worked. I traced out everything and found that one of the MISO lines back had no voltage on it, they use a couple of 3 input and gates for only select the signal going back cause I guess the theoy is that it will be logic low when the board is selected. Anyway got to looking and there are pullups on all the lines but for some reason not pulling up, figured out which resistor it was and when I tried to test it is was actually broke in two, replaced resistor and away it went. R296

[emdje]

In my understanding it means that if the application compiled against the vulnerable glibc does a gethostbyname() call it can be owned. Now since a miner typically resolves the IP of the pool it wants to connect to, the miner might be pretty easy to attack as you can relatively easy predict that it will resolve its pool sooner or later. It is unclear to my understanding if the DNS server your miner uses would discard an actual malformed answer that would trigger the vulnerability.

The firewall you have in front of your miners doesn't help anything here (except you have it locked down so much, that the miner only can connect to the pools ip and port, else the attacker just launches a reverse shell with nc or whatever is en vogue right now.
So theoretically you could just remove any DNS servers from your Pi (echo "" > /etc/resolv.conf) and instead of the name of your pool, add the IP of the pool in the web frontend (and hope your pool doesn't switch providers or whatever could make a change of IP necessary).

Other than that running "apt-get update; apt-get upgrade" and waiting for a new miner binary to be released there is not much we Terminator operators can do right now. Let's hope this will be before real exploits are being published. AFAIK there are currently only 2 PoC exploits in the wild which make it unlikely that the the average Terminator out there is targeted but that might change quickly once there is for example a module for metasploit.

True I can see that, for some reason I had not though about send a download and run type thing.

I was looking, I see the vulnerability for glibc but not really for eglibc, guess going to have to make a test bench somehow

eglibc is equally affected from the problem as far as I can judge:

i.e.: http://www.ubuntu.com/usn/usn-2485-1/

I am not that into coding and software as I would like. Do I read it correctly that because I have build the cgminer builds on the raspberry pi and not under Ubuntu that the builds are not vulnerable??

[emdje]

I have been working on a miner that I suscpected the contrller board died for some reason, I had built a replacement out of a CPLD but it is not the handiest thing to put in place so today I decided to figure this thing out. The device would not find any boards but I tested all of them one at a time and they worked. I traced out everything and found that one of the MISO lines back had no voltage on it, they use a couple of 3 input and gates for only select the signal going back cause I guess the theoy is that it will be logic low when the board is selected. Anyway got to looking and there are pullups on all the lines but for some reason not pulling up, figured out which resistor it was and when I tried to test it is was actually broke in two, replaced resistor and away it went. R296

Great that your got it working

[psycodad]

In my understanding it means that if the application compiled against the vulnerable glibc does a gethostbyname() call it can be owned. Now since a miner typically resolves the IP of the pool it wants to connect to, the miner might be pretty easy to attack as you can relatively easy predict that it will resolve its pool sooner or later. It is unclear to my understanding if the DNS server your miner uses would discard an actual malformed answer that would trigger the vulnerability.

The firewall you have in front of your miners doesn't help anything here (except you have it locked down so much, that the miner only can connect to the pools ip and port, else the attacker just launches a reverse shell with nc or whatever is en vogue right now.
So theoretically you could just remove any DNS servers from your Pi (echo "" > /etc/resolv.conf) and instead of the name of your pool, add the IP of the pool in the web frontend (and hope your pool doesn't switch providers or whatever could make a change of IP necessary).

Other than that running "apt-get update; apt-get upgrade" and waiting for a new miner binary to be released there is not much we Terminator operators can do right now. Let's hope this will be before real exploits are being published. AFAIK there are currently only 2 PoC exploits in the wild which make it unlikely that the the average Terminator out there is targeted but that might change quickly once there is for example a module for metasploit.

True I can see that, for some reason I had not though about send a download and run type thing.

I was looking, I see the vulnerability for glibc but not really for eglibc, guess going to have to make a test bench somehow

eglibc is equally affected from the problem as far as I can judge:

i.e.: http://www.ubuntu.com/usn/usn-2485-1/

I am not that into coding and software as I would like. Do I read it correctly that because I have build the cgminer builds on the raspberry pi and not under Ubuntu that the builds are not vulnerable??

Most advisories only talk about glibc, but I am pretty confident all previous versions of eglibc were vulnerable (no matter if ubuntu or debian):

https://www.debian.org/security/2016/dsa-3480

If you still have your build system available, just apt-get upgrade it and then make the binary again, that should be sufficient (eventually a make clean would be advisable before).

[mjgraham]

I have been working on a miner that I suspected the controller board died for some reason, I had built a replacement out of a CPLD but it is not the handiest thing to put in place so today I decided to figure this thing out. The device would not find any boards but I tested all of them one at a time and they worked. I traced out everything and found that one of the MISO lines back had no voltage on it, they use a couple of 3 input and gates for only select the signal going back cause I guess the theory is that it will be logic low when the board is selected. Anyway got to looking and there are pullups on all the lines but for some reason not pulling up, figured out which resistor it was and when I tried to test it is was actually broke in two, replaced resistor and away it went. R296

Great that your got it working

Yea I can about fix the boards as well, so far I have found all sorts of strange failures that were easy to fix, Still yet to try and pull and change a chip out.

[coinflow]

In my understanding it means that if the application compiled against the vulnerable glibc does a gethostbyname() call it can be owned. Now since a miner typically resolves the IP of the pool it wants to connect to, the miner might be pretty easy to attack as you can relatively easy predict that it will resolve its pool sooner or later. It is unclear to my understanding if the DNS server your miner uses would discard an actual malformed answer that would trigger the vulnerability.

The firewall you have in front of your miners doesn't help anything here (except you have it locked down so much, that the miner only can connect to the pools ip and port, else the attacker just launches a reverse shell with nc or whatever is en vogue right now.
So theoretically you could just remove any DNS servers from your Pi (echo "" > /etc/resolv.conf) and instead of the name of your pool, add the IP of the pool in the web frontend (and hope your pool doesn't switch providers or whatever could make a change of IP necessary).

Other than that running "apt-get update; apt-get upgrade" and waiting for a new miner binary to be released there is not much we Terminator operators can do right now. Let's hope this will be before real exploits are being published. AFAIK there are currently only 2 PoC exploits in the wild which make it unlikely that the the average Terminator out there is targeted but that might change quickly once there is for example a module for metasploit.

True I can see that, for some reason I had not though about send a download and run type thing.

I was looking, I see the vulnerability for glibc but not really for eglibc, guess going to have to make a test bench somehow

eglibc is equally affected from the problem as far as I can judge:

i.e.: http://www.ubuntu.com/usn/usn-2485-1/

I am not that into coding and software as I would like. Do I read it correctly that because I have build the cgminer builds on the raspberry pi and not under Ubuntu that the builds are not vulnerable??

Most advisories only talk about glibc, but I am pretty confident all previous versions of eglibc were vulnerable (no matter if ubuntu or debian):

https://www.debian.org/security/2016/dsa-3480

If you still have your build system available, just apt-get upgrade it and then make the binary again, that should be sufficient (eventually a make clean would be advisable before).

Could you explain what make does in detail? Does it include the glib-code (or parts of it) in the output or only links to the relevant things? If it does the latter, then would it not be sufficient to only upgrade the system and the previously compiled results then would point to the upgraded, non-vulnerable version?