BAMT version 0.5 - Easy USB based mining Linux with farm wide management tools

[lodcrappo]

I have been having a lot of issues w/ cgminer & 0.5.

This is not helpful.  What problems, when do they happen, what makes them happen, etc?

I should never have given this image the label "0.5". 

It seems to be giving people the impression that there is some difference between it and the last fix for 0.4 that simply isn't there.

Nothing changed?  Kernel? drivers? etc?

Anyways:
about 30% of the time cgminer fails to start on reboot.  rebooting again or starting manually has no problem.
sometimes when going into gpumon and pressing 0 I get "no screen matching cgminer found" but if I quit cgminer and do a screen -r it loads just fine (and yes the screen is named "cgminer").
BAMT reporting tools (gpumon, mgpumon, web gpumon, etc) show no data from cgminer (shares, MH/s, etc are 0).

Sorry I can't help more but at this point using 0.4b works flawlessly so I didn't dive deeper into it yet.  Maybe next weekend.

The only change in software versions is that 0.5 has cgminer 2.7.  No changes anywhere else.

Did you try using the cgminer bin you use on 0.4 on a 0.5?  Maybe my cgminer build is just buggy, sounds like all the problems are just it crashing.

[DeathAndTaxes]

Did you try using the cgminer bin you use on 0.4 on a 0.5?  Maybe my cgminer build is just buggy, sounds like all the problems are just it crashing.

I haven't tried that but I will. I don't think it is an issue of it just crashing (except maybe the first one) as cgminer is running, hashing just fine, and submitting shares without issue even when gpumon says no "screen" or it shows 0MH/s.  Likely there is some simple explanation but I haven't found it yet. 

As a temporary measure I just figured giga might want to install 2.2.7 binary on a working 0.4b image (hell could put it in another folder alongside default cgminer) and try to run it manually there.  If that works he can troubleshoot from there.

[lodcrappo]

Did you try using the cgminer bin you use on 0.4 on a 0.5?  Maybe my cgminer build is just buggy, sounds like all the problems are just it crashing.

I haven't tried that but I will. I don't think it is an issue of it just crashing (except maybe the first one) as cgminer is running, hashing just fine, and submitting shares without issue even when gpumon says no "screen" or it shows 0MH/s.  Likely there is some simple explanation but I haven't found it yet. 

As a temporary measure I just figured giga might want to install 2.2.7 binary on a working 0.4b image (hell could put it in another folder alongside default cgminer) and try to run it manually there.  If that works he can troubleshoot from there.

sure.  can probably copy 2.7 from any "0.5" bamt image into a 0.4 disk for that matter.  but i am not sure thats a good idea with the stability issues.

when cgminer works but bamt can't talk to it, usually means the API handling part of cgminer has died.  often I see that happen as a precursor to cgminer totally locking up (or even taking down the entire rig, which always sucks).  but maybe it also can happen and then cgminer goes on like a zombie without communication to the outside world.  maybe possibilities.

[phr33]

Root password is not "changeme"?

[BitMinerN8]

Root password is not "changeme"?

It is the same. changeme

EDIT -> Not same in 0.5b
See notes at http://bamter.org/download.html

[lodcrappo]

Root password is not "changeme"?

is this a question, a statement, are you trying to say you are having trouble?

[phr33]

Root password is not "changeme"?

is this a question, a statement, are you trying to say you are having trouble?

Sorry I was unclear. Just too eager to get it up and running

Yes, I had touble. 'changeme' did not work. I downloaded bamt_v0.5b.img and copied from BAMT/CONF/FROM to BAMT/CONF/TO.

I have now booted the stick on a box with a screen attached. There I could set the password in the root terminal. New password worked.

Im pretty sure I didn't mess up when trying with 'changeme'. I tried like 10 times.

[lodcrappo]

Root password is not "changeme"?

is this a question, a statement, are you trying to say you are having trouble?

Sorry I was unclear. Just too eager to get it up and running

Yes, I had touble. 'changeme' did not work. I downloaded bamt_v0.5b.img and copied from BAMT/CONF/FROM to BAMT/CONF/TO.

I have now booted the stick on a box with a screen attached. There I could set the password in the root terminal. New password worked.

Im pretty sure I didn't mess up when trying with 'changeme'. I tried like 10 times.

looks like the password is back at debian live defaults in 0.5b.  I was thinking about doing that anyway, not sure how it happened this time but I think we'll go with it.

Debian live just doesn't set a root password, which is a lot safer than using one everybody knows.  Going forward, same for BAMT.

The stock user account is still there same as always, 'user' w/ pass 'live'.  you can ssh in as user and use 'sudo passwd' to set the root password to anything you like.

No loss of functionality, just enforcing to change the root pw. a good thing imho.

let the hordes of "omgwtf i cant login" begin.. sigh...

[jamesg]

I have been having a lot of issues w/ cgminer & 0.5.

This is not helpful.  What problems, when do they happen, what makes them happen, etc?

I should never have given this image the label "0.5". 

It seems to be giving people the impression that there is some difference between it and the last fix for 0.4 that simply isn't there.

Nothing changed?  Kernel? drivers? etc?

Anyways:
about 30% of the time cgminer fails to start on reboot.  rebooting again or starting manually has no problem.
sometimes when going into gpumon and pressing 0 I get "no screen matching cgminer found" but if I quit cgminer and do a screen -r it loads just fine (and yes the screen is named "cgminer").
BAMT reporting tools (gpumon, mgpumon, web gpumon, etc) show no data from cgminer (shares, MH/s, etc are 0).

Sorry I can't help more but at this point using 0.4b works flawlessly so I didn't dive deeper into it yet.  Maybe next weekend.

I get these same issues on 0.4 where when a gpu is dead in cgminer, i coldreboot only to come back 10 minutes later and xOrg is taking up 99% cpu. I've just worked around it up to this point because lodcrapppo has enough to do I'm sure.

To be clear, this only happens on 4 out of 18 rigs.

[gnar1ta$]

Ok. I have BAMT 0.5 setup on a single rig and it was very straight forward. Awesome!

Bad news. When I add the -scan-serial option to the cgminer config and try to restart the mining process, the start process dies. I'm assuming this is because of one of the following reasons.

- cgminer 2.2.7 does not work for some reason with BFL stuff.
- cgminer does not work with debian for some reason.

I am going to have to get with BFL to see if I can get some answers around what linux distros they have been testing with.

I'll keep you up-to-date.

gigavps did you try to run cgminer manually (cd to /opt/miners/cgminer and run ./cgminer <opts>)?

I have been having a lot of issues w/ cgminer & 0.5.  You may want to try installing cgminer 2.2.7 on BAMT 0.4b.  You will need a 32bit binary.  If you search the cgminer thread there is a link someone was kind enough to compile and host it for me.

If your refering to the binary I put up, it wasn't compiled with bitforce.  I can compile another easy enough though if it will help.

[DeathAndTaxes]

If your refering to the binary I put up, it wasn't compiled with bitforce.  I can compile another easy enough though if it will help.

Err oops I wasn't aware of that.

[lodcrappo]

It's quite simple to build any version you want of cgminer in bamt.  All of the tools you need are built in.

Simply download the source tar from cgminer thread and follow the instructions that are included.  They work exactly as written.

[gnar1ta$]

It's quite simple to build any version you want of cgminer in bamt.  All of the tools you need are built in.

Simply download the source tar from cgminer thread and follow the instructions that are included.  They work exactly as written.

On .4 I had to install libncurses-dev and libcurl4-openssl-dev and define CFLAGS instead of just using the normal CFLAGS="-O2 -Wall -march=native" ./configure, but I suck at Linux so there may be an easier way.  This has worked for me on 6 installs though.

[Inaba]

So I am trying this out, and at least one of the machines will just randomly reboot.

I don't mean it crashes and then does a hard reboot - the system does a graceful reboot and the console gives the System going down now, reboot message.  What gives?  Why is it doing this?  It's kind of annoying.

I don't think any machine should ever reboot on it's own unless explicitly set to do so, which I have not done.  how do I prevent it from doing this?

[TheHarbinger]

So I am trying this out, and at least one of the machines will just randomly reboot.

I don't mean it crashes and then does a hard reboot - the system does a graceful reboot and the console gives the System going down now, reboot message.  What gives?  Why is it doing this?  It's kind of annoying.

I don't think any machine should ever reboot on it's own unless explicitly set to do so, which I have not done.  how do I prevent it from doing this?

I had a board that would do this also.  It was totally untraceable.  Would run stable for days some times, others it would reboot 4 or 5 times a day.  Changed hardware, changed software, beat my head on various walls, nothing helped.  I stripped everything from the mobo with the intent of smashing the hell out of it one day, Office Space style.  Noticed a "smudge" of some sort on the back of the board, some unidentifiable substance clinging there like a someone with a cold sneezed before the board got packaged.  I wiped it off with some alcohol swabs and reinstalled everything.  Disco.  Whatever the hell it was, was causing something to randomly short out and reboot the board.  I never inspected the board before I built the system, just pulled it from the box, and installed everything.  Now, I very carefully check every component before I do an install.


Back on topic;

I have the same issues as D&T is having with the 0.5 release, don't know if it is BAMT related or a cgminer thing, so until I have the time, and energy to track it down, going to stick with the 0.4. 

[Inaba]

You are saying it would gracefully shutdown in Linux due to this?

[DeathAndTaxes]

You are saying it would gracefully shutdown in Linux due to this?

It is very unlikely but possible.  ATX power switch is "soft" meaning shorting it will cause MB to send power off signal to the OS rather than kill power directly.  On some motherboards (but not the 890FXA-GD70 grr) you can change this to be instant off (no holding for 5 seconds to hard poweroff).  IF you did that and the problem switched to hard power down it likely is a short.  

If you have any switch connected to the power switch header you could also try removing it and see if the problem goes away.  If it does then power switch itself likely has an intermittent short.  Personally I don't use any power switches.  Just set BIOS to power on after power loss and use the power supply and then use the AC power switch on PSU.

[Inaba]

No switch hooked to the MB and nothing is shorting it. 

I have another machine that's doing it now, as well, and it works just fine with my standard USB Ubuntu install... only with BAMT does it do the reset thing.  So it's definitely BAMT doing it.

[jamesg]

No switch hooked to the MB and nothing is shorting it. 

I have another machine that's doing it now, as well, and it works just fine with my standard USB Ubuntu install... only with BAMT does it do the reset thing.  So it's definitely BAMT doing it.

The only time I have ever seen a machine reboot for no reason in my cluster is because one of the two PSUs was overloaded or the fan on the PSU had stopped working.

[DeathAndTaxes]

No switch hooked to the MB and nothing is shorting it. 

I have another machine that's doing it now, as well, and it works just fine with my standard USB Ubuntu install... only with BAMT does it do the reset thing.  So it's definitely BAMT doing it.

The only time I have ever seen a machine reboot for no reason in my cluster is because one of the two PSUs was overloaded or the fan on the PSU had stopped working.

That wouldn't cause a soft reboot.

i.e. "shutting down" message in the OS.  It would be a hard power trip.