Works also fine with Scrypt miners 

Not meant to answer on behalf of Sampey, but I run C.A.T. on a VPS on Ubuntu Linux with xrdp. Whenever I want to access C.A.T. I connect to the xrdp service from anywhere.
HTH

Did I miss anything yesterday?

Don't know about the others, but C.A.T. has been around a long time and works very stable. On top of that Sampey is a great, helpful and honest guy. I would definitely buy it again.

Those are three pools I have used, but there are certainly gazillions of other reliable scrypt pools out there:

• https://www.litecoinpool.org/
• https://ltc.suprnova.cc/
• http://xpool.ca/

Also make sure to check the Pool section in the altcoin board.

The diff you are mining at (256) is way too high for your hashrate (~270kh/s), there will be new work before you are able to submit a share most of the time.
I have a small USB miner with about the same scrypt hashrate and it mines at a diff of 8 on a multipool vardiff port. I would recommend with that hashrate to not mine with a difficulty over 32.
HTH

I can provide one or more managed nodes for a coin if needed.
However I personally also recommend you just get an ultracheap vps and do it yourself.
PM me if interested.

Yobit wallet is in maintenance since days, wish I could stake with the coins stuck there.

Interesting.. but what will keep others from compiling the sketch on their (imaginary) 512-core big iron and instamining all coins ?
I'll be watching, but I have serious doubts.

http://xpool.ca/ mines it as auxpow.

Hi,

d57heinz is certainly right, this looks a lot like a dragon 30Mh/s scrypt miner with B2 chips.
The 4 blades of the miner seem to be recognized properly in your system (/dev/ttyUSB0-3) and its probably only a matter of letting it hash against a scrypt pool like litecoinpool.org as d57heinz proposed.

HTH

According to https://bitcointalk.org/index.php?topic=392436.msg12348595#msg12348595 Monacoin will move to Lyra2REv2 in ~5000 blocks. If I understand this correctly scrypt will not be supported anymore then.

Heya crackers
IMHO there are about 4850 blocks left to the fork @450000.

Cheers

As promised here is a howto explaining the growing and shrinking of SD card images and filesystems.

Growing is useful if you want to grow the filesystem from your image to take advantage of all space available on your SD card.
Shrinking is useful if you want to write i.e. an 8GB image to a 2GB SD card (given the content of the image is less than 2GB).

You will need a Linux computer with gparted installed. Many Live-CDs for Linux and BSDs that include gparted can be used so you can use these steps without devoting a computer to Linux permanently (though you really should ).

We will first deal with growing an image to your SD cards full size, since that is slightly easier to do (nvm, shrinking is not that hard either).

Growing an image on the SD card
First write the image you have downloaded from the OP to your 8GB SD card with something like


Make sure that you use the correct device for sdX in the above /dev/sdX!
The below two commands help you to identify the device name of your SD card:

If you just have plugged it in, check the output of the below command (the last lines to find out what device name your SD card has)

[1883229.800218] scsi119 : usb-storage 8-2:1.0
[1883230.804097] scsi 119:0:0:0: Direct-Access     USB2.0   CARD-READER      1.01 PQ: 0 ANSI: 2
[1883230.804824] sd 119:0:0:0: Attached scsi generic sg2 type 0
[1883230.814085] sd 119:0:0:0: [sdb] Attached SCSI removable disk
[1883230.831082] sdb: detected capacity change from 7948206080 to 0
[1883230.844116] sd 119:0:0:0: [sdb] 15523840 512-byte logical blocks: (7.94 GB/7.40 GiB)
[1883230.850080] sd 119:0:0:0: [sdb] No Caching mode page found
[1883230.850084] sd 119:0:0:0: [sdb] Assuming drive cache: write through
[1883230.866076] sd 119:0:0:0: [sdb] No Caching mode page found
[1883230.866080] sd 119:0:0:0: [sdb] Assuming drive cache: write through
[1883230.880111]  sdb: sdb1 sdb2


The other command below shows your partition tables, look for one that looks like the size of your SD card:

On my PC with one 80GB harddisk (sda) the output looks like:
major minor  #blocks  name

   8        0   78150744 sda
   8        1     498688 sda1
   8        2          1 sda2
   8        5   39061504 sda5
   8        6    3905536 sda6
  11        0    1048575 sr0
   8       16    7761920 sdb
   8       17      57344 sdb1
   8       18    2831360 sdb2
Obviosuly, /dev/sdb is the SD card with 8GB capacity.

Once the image is written to your SD card, run the following command (again replacing /dev/sdX with your device name):

A window like the following will appear:


Make sure that all partitions are unmounted by right-clicking them and selecting "unmount". You will not be able to resize the partition and filesystem while it is mounted:


Now you are ready to resize. Right-click on the partition /dev/sdX2 (sdb2 in my case) and select Resize/Move:


A new window will appear that allows you to resize:


Grab the right edge with your mouse and drag it completely to the right:


You can also enter values directly below instead of dragging with your mouse.
Once you are done, press Resize/Move.

A warning will eventually appear that you can safely ignore if you did everything right until here.

Now select Edit|Apply All Operations and give it some minutes to do its job:


Once this has finished, your image is resized to the full SD card size and you can start to use it in your miner.

Shrinking an image file to fit on a smaller card
Now this gets a bit more work as we need to do all work on the image file as we obviously can't just dd it to a smaller card and work on the card directly. Still it is very easy to do so:

First of all we need to mount the image to work on its filesystem. Linux offers the loop device system for such tasks. To create a device from the ANX image do as follows:

Now you can again run gparted but against the loop device:

As above in growing the filesystem you can now shrink the second partition to your needs. In our case I want to make the image to fit on a 2GB SD card. Since the boot partition needs some space and we do not want to stretch our luck too much, we make the partition ~1700MB:

Note:Actually one could make some maths to get the right matching number for partition size, but that's beyond the scope of this howto and in this case I don't mind wasting a few MB. In fact the image, after written to SD card can simply be grown to the full 2GB size of the target card with above growing procedure.

Again apply these changes by selecting "Edit|Apply All Operations" and get yourself a coffe (better two).

Once things are done from gparted we are left with an image that would fit on 2GB SD card but has ~6GB unused space at the end and actually is still an 8GB image.
So to be able to dd it to our 2GB sd card we need to truncate the image to the space currently used.
First we need to find out where out second partition we just resized now ends:

Which will give you an output like below:
Disk AnxA2-09012015.img: 7948 MB, 7948206080 bytes
255 heads, 63 sectors/track, 966 cylinders, total 15523840 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0002c262

             Device Boot      Start         End      Blocks   Id  System
AnxA2-09012015.img1            8192      122879       57344    c  W95 FAT32 (LBA)
AnxA2-09012015.img2          122880     3809279     1843200   83  Linux

The important number is the last block of the last partition: 3809279

From the above output we also know that the block size is 512 bytes. That leaves us with the following formula to determine where we will be truncating the image:

(3809279+1) * 512 = 1950351360

Note: the +1 is because blocks count from 0 so we adjust for that with one block added.

Now can trim our image to the size we calculated above:

You should now be able to dd the above image to a 2GB SD card disk.

I hope this helps one or the other when fiddling with images. If you have feedback or corrections please let me know.

To be honest, I just cut power to them with Ethernet PDUs.
I have meanwhile 4 kinds of different IP-PDUs: Very old Aviosys 4- and 8-Port, an old Epower Switch, an ALIX Board with a USB Relay from Cleware and my latest one is the RT5350F-OLinuXino-EVB. The ALIX runs on voyage linux and the Olinuxino with OpenWRT. On both I have a cgi script running that exposes the same API as the Aviosys IP-Switch. All IP-PDUs are controlled from a script that constantly monitors coin price, difficulty, env. temperature in basement, current electricity price and based on this switches only on if my script thinks it can make profit...

I am not sure if this is good. Imagine people having a miner in a datacenter in a remote place and accidentally clicking shutdown. For me I can do the shutdown via ssh with public key auth. But you are right in that shutting down the thing properly would be the way to go. I think I will have to add that to my script so that it shuts the Pi's down a few seconds before switching off power.

Ok, will be my next post, but it might take some time to get it put together.

From my past experience there are a few ways to acomplish that:

• Use Debians packages and have your own repo, run apt-get -y upgrade from cron.
  This would be the most professional way and it could even run automatically. But building Debian packages for every single file you, Innosilicon and others have added to the base image would be huge task. And there are really simpler things in life than running a debian repo...
• Ship the image with 2x <4GB partitions, one is active and will be mounted as rootfs, the other on inactive.
  If the user wants to update, download a tar file and extract it to the inactive partition (or dd an image), once inactive partition is populated and was checked, switch uboot to boot from this partition, making the other one now the inactive one.
  This is a nice way, but it might be easy to f*ck up uboot configuration, leaving the user with a non-working miner and the urgent need to reflash. OTOH, you can offer in the GUI to switch back to the previous version by changing uboot configuration to point to the currently inactive partition, giving basically a way to go back to the old version. Naturally you could also copy over all config to the newly populated partition.
• Something I would call differential updates: Basically you make your current vanilla image the baseline image and work in a separate copy of the baseline image. Once you are ready to realease changes you run rsync in dry mode (meaning it doesn't sync but onyl report what it would do) and pipe the resulting filelist through tar. This will pack you all files that have changed compared to the baseline image. Naturally you would have to manually exclude files like the rrd's that may have been created in your tests etc..
  These updates can be then applied by just unpacking over the installation. A great disadvantage is that you have to take care yourself of restarting things etc or even stopping services before you are going to overwrite critical files. Basically you want to include a script with a defined name in the archive that does all that before and after the updates have applied (i.e. before: stop webservice, after: reboot).
  

Given that I think you will be only replacing very few files, the last option sounds like best. I have done this for a prototype of an embedded appliance that needed to autoupdate a few years ago.


Sounds all very promising. All update methods I described preserve (or let you preserve) configs.

Thank you for your feedback. The mentioned 88 has one blade that gives upto 3-5% errors when run at 1200MHz, when I change this one blade to 1000MHz, I feel like I get overall better results from this specific miner. Otherwise its a nice feature to check how a specific blade behaves at a specific speed but admittedly except the above 88 all my other miners run at the same speed on all their blades.


Great, having a stable and solid fs is important to me as my miners are getting switched on/off automatically. So there are days with 2-3 on/off transitions and having a lot of possible writes to the SD card ongoing makes me fear I am going to replace the first SD cards soon.
I would propose to have a picture with the images shipped which is just blank and has a text saying, "please wait a few minutes for statistics to be generated". This could be in place when the firmware first starts so you do not have broken links (i.e. if the graphs do not exist, copy the empty image there at boot).
For running I would propose to save the rrd databases regulary on the SD card somewhere, say every 1h. That is not perfect as it still gets the SD card some writes, but it reduces them a lot. If you i.e. tar.gz all rrd databases that should take minimal space and reduce writes even more. On boot, just check if the backup is existing and populate the tmpfs with the backup files.
I would even rotate those snapshots (having 2 of them, latest and latest+1) so that in case the switchoff happens when the tar.gz is built you have a working archive, so if unpacking the latest returns an error from tar, go for the latest+1.


Exactly, and a selection to work on group 1 or 2. I was quite happy with that feature to quickly change where and what I mine without loosing all the primary pools and worker-logins (it's not much of a deal but I found it very comfortable).


Nice, I'd be happy to offer a howto on growing or shrinking the images (i.e. growing the 4GB image to an 8GB card or to shrink the 4GB for a 2GB card).

I think you will need jmordica's fork of cgminer from https://github.com/jmordica/cgminer-gc3355 .

Configure parameters are noted in the readme of the above link. Otherwise you just need to make sure you have all the requirements/dependencies installed to build it on your Pi.

HTH

Thank you for your continous great work, awesome firmware!

The temperature and hashrate graphs are an enormous help!
DHCP by default eases life a lot when setting them up or upgrading, the same goes for timezone setting.

A few questions and wishes though:

• With emdje's fw I was able to set the speed of each blade separately, this would be a nice option as my 88 wants to run one of six blades at a lower speed for best performance
• Are you considering to put the 2 cdmrrd directories on a tmpfs to have less write on the SD card (I like the graphs, but I fear they could wear out the SD card quite quickly)?
• How about taking the primary configured pool as ping target ?
• A secondary pool config to switch to would be nice but it's not that big deal

Also I noticed the image is 8GB in size, but the partitions inside account only for about 2.8GB. May I propose to either grow the fs to use the remaining space and/or create an image that also fits on 2GB/4GB cards. (Actually I use it with all 3 sizes of cards)

I would be happy to help with all of the above ideas/wishes, just let me know what I can contribute.

Please do not confuse cloud mining ponzis with miner rental services like miningrentals (never worked with them), betarigs or nicehash.

With all of the above miner rentals you choose where to point the hash to, unlike with cloud mining where you get some profit based on some shady calculations.
I am personally using betarigs and nicehash a lot and can say they are completely legit and honest in what they offer.

And you can solo mine with them either on your private pool or - which is probably a very bad idea - pointing them directly to the rpc of your coind.

I would say no. You would at least need shell access and the ISP's TOS should allow you to run other programs which most web hosts don't.

Better get a VPS if you want to run a full node.

HTH