OLD: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30

[xyzzy099]

Facing some compile issues from git version

I did a make clean in the ~/bfgminer directory
I did a git pull to update new source.
./configure
./make

make fails with following tail:

make[5]: Nothing to be done for 'all-am'.
make[5]: Leaving directory '/home/minepeon/bfgminer/lib'
make[4]: Leaving directory '/home/minepeon/bfgminer/lib'
make[3]: Leaving directory '/home/minepeon/bfgminer/lib'
  CC       bfgminer-miner.o
miner.c:102:21: fatal error: version.h: No such file or directory
 #include "version.h"
                     ^
compilation terminated.
Makefile:1141: recipe for target 'bfgminer-miner.o' failed
make[2]: *** [bfgminer-miner.o] Error 1
make[2]: Leaving directory '/home/minepeon/bfgminer'
Makefile:2211: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/minepeon/bfgminer'
Makefile:862: recipe for target 'all' failed
make: *** [all] Error 2


What am I missing?

Thank you.

Announcing BFGMiner 4.4, the modular cryptocurrency miner written in C. BFGMiner features dynamic clocking, monitoring, and remote interface capabilities.

If you are pulling from git, you need to run ./autogen.sh before ./configure.

[1714820623]

1714820623

[1714820623]

1714820623

[xyzzy099]

I'm getting an "invalid address" error when attempting to solo mine. Coin is GlobalBoost.

BFGMiner 4.4.0, OS X Mavericks w/ Zeus Blizzard.

Cmd line: bfgminer --scrypt -o http://127.0.0.1:port -u user -p pwd --coinbase-addr GYLaG8VgEwHjfLWvYnyCGCzQgMVHMbEo87 -S zus:/dev/cu.SLAB_USBtoUART

What am I missing ?

Thanks,
~ Jay

You can only use valid bitcoin addresses - alt coin addresses will not work.

If you are pulling from git, you need to run ./autogen.sh before ./configure.

I'm using the binary available here.  Maybe I'll try compiling it.

Sorry, I clicked on the "quote" button of the wrong message.

Your problem has nothing to do with compiling.  You simply cannot use BFGMiner's GBT solo-mining mode to mine alt coins.  The coinbase address HAS to be a BITCOIN address.

[Luke-Jr]

Anyone with a (real) Icarus kicking around? Would be nice to test that some recent changes don't break it, if possible...

[coinb0y]

If you are pulling from git, you need to run ./autogen.sh before ./configure.

[minepeon@minion bfgminer]$ ./autogen.sh           
Getting submodules...
Running autoreconf -if...
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
Makefile.am:40: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
Updating version.h...
cmp: version.h: No such file or directory



It is still pointing to version.h

[Luke-Jr]

Code:

cmp: version.h: No such file or directory

It is still pointing to version.h

This is expected on a fresh clone (or the first update since a few days ago).

[nst6563]

I got around the version.h by doing a git describe >>version.h.  May not be the right way but it worked.

[Luke-Jr]

I got around the version.h by doing a git describe >>version.h.  May not be the right way but it worked.

I'm surprised, that should break the build...

Edit: I bet it immediately replaced yours

[nst6563]

I got around the version.h by doing a git describe >>version.h.  May not be the right way but it worked.

I'm surprised, that should break the build...

Edit: I bet it immediately replaced yours

It compiled just fine after that as I didn't run autogen, just reran make. 
I've also since switched to a straight raspbian image and recloned and rebuilt it...didn't have the version.h error this time.

But bfgminer seems to have a problem with manicminer pool and it didn't seem to play nice with nicehash.  Worked ok with coinking, but I noticed that the hashrates were a little strange....first 2 numbers were in the hundreds, last number was 23mhs.  I'm running a Falcon/Thunder x3 and it's consistently running around 29mhs with cgminer.  I was just trying to give bfgminer a shot due to the success others seem to be having with it.  I don't seem to have that sort of luck it seems though 

[nwoolls]

But bfgminer seems to have a problem with manicminer pool and it didn't seem to play nice with nicehash.  Worked ok with coinking, but I noticed that the hashrates were a little strange....first 2 numbers were in the hundreds, last number was 23mhs.  I'm running a Falcon/Thunder x3 and it's consistently running around 29mhs with cgminer.  I was just trying to give bfgminer a shot due to the success others seem to be having with it.  I don't seem to have that sort of luck it seems though  

Try regular pools. As a rule of thumb, mult-pools don't work. This is not driver-specific.

[philipma1957]

how do I write a bfgminer.conf file

I am at this point on bfgminer 4.4.0  I would need to see someone elses so I can copy it and paste in

 my bitsolo and my btc address. I use 3 nanofury singles and 3 nano fury 2x usb sticks

[hurricandave]

^^^ just press enter and the config file will be written and named with the default bfgminer.conf   it looks like you have already entered the bitsolo  and  btc address as well as discovered the devices.

[philipma1957]

^^^ just press enter and the config file will be written and named with the default bfgminer.conf   it looks like you have already entered the bitsolo  and  btc address as well as discovered the devices.

 thanks dave works fine.

 I feel stupid that I have never asked this question.  I did not know it was so easy to do it.

I could do this again and put in a roll over pool correct?

[zyberguy]

@nwoolls

Could you make a firmware with bfgminer on tplink MR3020?
The WR703n is not easy to find. For my area the WR703n is totally replace with MR3020.
I know the cpu are the same but dont know if they can interchangable with flashing.

Thanks

[nst6563]

But bfgminer seems to have a problem with manicminer pool and it didn't seem to play nice with nicehash.  Worked ok with coinking, but I noticed that the hashrates were a little strange....first 2 numbers were in the hundreds, last number was 23mhs.  I'm running a Falcon/Thunder x3 and it's consistently running around 29mhs with cgminer.  I was just trying to give bfgminer a shot due to the success others seem to be having with it.  I don't seem to have that sort of luck it seems though  

Try regular pools. As a rule of thumb, mult-pools don't work. This is not driver-specific.

I never said it was driver-specific, just that it doesn't work with those pools.  Coinking is also a multipool.  So is there a programmatic reason that it doesn't work with certain pools while cgminer tends to not care and just works?

[nwoolls]

I never said it was driver-specific, just that it doesn't work with those pools.  Coinking is also a multipool.  So is there a programmatic reason that it doesn't work with certain pools while cgminer tends to not care and just works?

Luke would have to speak to the specifics, I am just passing along what I've been told about the issue.

[suzukii]

Hi all.   I don't know if the following is something I did or didn't do but here is my case.  

I'm not sure if my issue is a bug or something stupid I may have overlooked when upgrading from v4.2.0 to v4.3.0, (when my problems started), with minimal dysfunctionality to upgrading to v4.4.0 with random blades just not hashing at all.
FYI I posted this somewhere else but can't recall where.  So I'll risk a slap on the cheek in reposting this.


The problem:

Minepeon had worked quite well for me with bfgminer v4.2.0 since it's v4.2.0. release.  
So I forgot Murphy's Law: "if it ain't broke, don't fix it"./b].
I was following the steps at this link in another forum: Upgrade bfgminer to v4.2.0., until I decided to try the same steps to upgrade to v4.3.0 version & the v4.4.0.  
Now, all I have are my gridseed g-blades dropping off after 2-3 hours (this didn't happen with v4.2.0) & not all will hash anymore.  Out of the 3 g-blades, each consisting of two boards, only 5 1/2 boards will hash, which randomly changes to another board not hashing, every time I restart bfgminer v4.3.0 or v4.4.0.


What I've done to try to correct, (noobie here so pls keep the laughter to a minimum if I did silly stuff)

(1) I unplugged & reseated all my cables (just incase gremlins)
(2)I reinstalled Minepeon v2.4.6 for Raspberry Pi model B onto a new SD card, performed the normal "git pull" & "pacman -Syu" commands.
(3) configured my fave pool, wemineltc.com.
(4) upgraded bfgminer to v4.3.0 a few days ago.
(5) then upgraded again a few hours ago or soon as I saw the forum post of it's new release, I forget.

This is what my config looks like in Minepeon for bfgminer:
#!/bin/bash
sleep 10
/usr/bin/screen -dmS miner /opt/minepeon/bin/bfgminer-gridseed --scrypt -S gridseed:all --set-device gridseed:clock=838 --failover-only -c /opt/minepeon/etc/miner.conf

(The snapshots at the bottom are recent ones after a restart 45 minutes later & the same after 6 hours last night of mining on my choice LTC pool www.wemineltc.com just to see if something had changed.)



...and...





If you request some type of logging texts from me please also show me how this is done, since I'm not knowledgable with linux.


PS: Can someone explain the steps required to downgrade from bfgminer v4.4.0 back to v4.2.0 on Minepeon/ArchLinux which worked quite well for me until I decided to try the new bfgminer v4.3.0 version & the v4.4.0.  


Thanks.

[nwoolls]

Now, all I have are my gridseed g-blades dropping off after 2-3 hours (this didn't happen with v4.2.0) & not all will hash anymore.  Out of the 3 g-blades, each consisting of two boards, only 5 1/2 boards will hash, which randomly changes to another board not hashing, every time I restart bfgminer v4.3.0 or v4.4.0.

While I'd encourage you to try v4.2 again, there are known issues where GridSeed devices (DualMiners, Blades, Orbs, etc) stop generating nonces / shares. It's there in other drivers as well, for CPUMiner and CGMiner.

The next version of BFGMiner will include a new feature of the current watchdog to watch for nonces found by devices and compare those to pool difficulty. Basically if a device isn't generating shares anymore, it will be caught by the watchdog. In addition the GridSeed drivers (DualMiner and GridSeed) will reinitialize the device when this happens.

[nwoolls]

@nwoolls

Could you make a firmware with bfgminer on tplink MR3020?
The WR703n is not easy to find. For my area the WR703n is totally replace with MR3020.
I know the cpu are the same but dont know if they can interchangable with flashing.

Want to send me one?   I'd be happy to make a build if you wanna send one or donate $45 USD in BTC or something similar.

Or if you take a look at the repo I've posted, the scripts are all commented and should be capable of building for that router with a few changes. Check out the shell scripts here:

https://github.com/nwoolls/BFGMiner-OpenWrt-Tools

[Luke-Jr]

But bfgminer seems to have a problem with manicminer pool and it didn't seem to play nice with nicehash.  Worked ok with coinking, but I noticed that the hashrates were a little strange....first 2 numbers were in the hundreds, last number was 23mhs.  I'm running a Falcon/Thunder x3 and it's consistently running around 29mhs with cgminer.  I was just trying to give bfgminer a shot due to the success others seem to be having with it.  I don't seem to have that sort of luck it seems though  

Try regular pools. As a rule of thumb, mult-pools don't work. This is not driver-specific.

I never said it was driver-specific, just that it doesn't work with those pools.  Coinking is also a multipool.  So is there a programmatic reason that it doesn't work with certain pools while cgminer tends to not care and just works?

BFGMiner has always had blockchain tracking code to minimise stale shares and avoid broken pools. As a side effect, it breaks when trying to use multiple blockchains - hence the warning in README.
This has always been true of cgminer as well.
So... when it "works", it's pretty much coincidence and could stop "working" at any time.

[suzukii]

Now, all I have are my gridseed g-blades dropping off after 2-3 hours (this didn't happen with v4.2.0) & not all will hash anymore.  Out of the 3 g-blades, each consisting of two boards, only 5 1/2 boards will hash, which randomly changes to another board not hashing, every time I restart bfgminer v4.3.0 or v4.4.0.

While I'd encourage you to try v4.2 again, there are known issues where GridSeed devices (DualMiners, Blades, Orbs, etc) stop generating nonces / shares. It's there in other drivers as well, for CPUMiner and CGMiner.

The next version of BFGMiner will include a new feature of the current watchdog to watch for nonces found by devices and compare those to pool difficulty. Basically if a device isn't generating shares anymore, it will be caught by the watchdog. In addition the GridSeed drivers (DualMiner and GridSeed) will reinitialize the device when this happens.

That sounds promising.  



Doh!!!! ...there goes one of my G-blades zero hashing again.