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

guinness

newbie

Activity: 20

Merit: 0

Quote from: gnar1ta$ on February 27, 2012, 03:34:13 PM

Quote from: guinness on February 27, 2012, 03:17:11 PM

I've had a problem using ssh on OSX to monitor miners. No problem with puTTY on Windoze. Go figure. The following allows ssh access to gpumon from OSX (10.6. Cool

ssh.

ssh -X user@
password:
sudo su
chmod uog+rw /dev/ati/card*
xauth merge /home/user/.Xauthority
export DISPLAY=:0
aticonfig --odgc --adapter=all

Wierd, I've always been using OSX and have had an issue the last week with a rig not mining and seg faulting. I resolved it last night with something similiar, but I have not seen the error before that and have been using BAMT for quite some time.

I have no problem with the 0.4 miners, just the one I've upgraded to 0.5b as a test.

gnar1ta$

donator

Activity: 798

Merit: 500

Quote from: guinness on February 27, 2012, 03:17:11 PM

I've had a problem using ssh on OSX to monitor miners. No problem with puTTY on Windoze. Go figure. The following allows ssh access to gpumon from OSX (10.6. Cool

ssh.

ssh -X user@
password:
sudo su
chmod uog+rw /dev/ati/card*
xauth merge /home/user/.Xauthority
export DISPLAY=:0
aticonfig --odgc --adapter=all

Wierd, I've always been using OSX and have had an issue the last week with a rig not mining and seg faulting. I resolved it last night with something similiar, but I have not seen the error before that and have been using BAMT for quite some time.

guinness

newbie

Activity: 20

Merit: 0

I've had a problem using ssh on OSX to monitor miners. No problem with puTTY on Windoze. Go figure. The following allows ssh access to gpumon from OSX ( 10.6.8 ) ssh.

ssh -l root@
password:
chmod uog+rw /dev/ati/card*
xauth merge /home/user/.Xauthority
export DISPLAY=:0
aticonfig --odgc --adapter=all

jamesg

vip

Activity: 1358

Merit: 1000

AKA: gigavps

Quote from: jamesg on February 27, 2012, 02:01:02 PM

lodcrappo,

Would BAMT somehow keep ftdi_sio from writing new devices it finds to the /dev folder?

Thanks,
gigavps

Upon further inspection of BAMT, it looks like the kernel mod ftdi_sio does not exist. According to luke-jr, this kmod is needed to allow the kernel to write /dev/ttyUSB* files when new USB devices are found.

jamesg

vip

Activity: 1358

Merit: 1000

AKA: gigavps

lodcrappo,

Would BAMT somehow keep ftdi_sio from writing new devices it finds to the /dev folder?

Thanks,
gigavps

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: jamesg on February 27, 2012, 09:27:45 AM

Quote from: Inaba on February 27, 2012, 08:55:15 AM

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.

jamesg

vip

Activity: 1358

Merit: 1000

AKA: gigavps

Quote from: Inaba on February 27, 2012, 08:55:15 AM

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.

Inaba

legendary

Activity: 1260

Merit: 1000

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.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: Inaba on February 27, 2012, 07:47:05 AM

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

legendary

Activity: 1260

Merit: 1000

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

TheHarbinger

sr. member

Activity: 378

Merit: 250

Why is it so damn hot in here?

Quote from: Inaba on February 27, 2012, 12:08:27 AM

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

legendary

Activity: 1260

Merit: 1000

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?

gnar1ta$

donator

Activity: 798

Merit: 500

Quote from: lodcrappo on February 26, 2012, 04:15:01 PM

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.

lodcrappo

hero member

Activity: 616

Merit: 506

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.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: gnar1ta$ on February 26, 2012, 04:09:26 PM

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.

gnar1ta$

donator

Activity: 798

Merit: 500

Quote from: jamesg on February 26, 2012, 01:40:29 PM

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 )?

Quote from: DeathAndTaxes on February 26, 2012, 02:20:56 PM

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.

jamesg

vip

Activity: 1358

Merit: 1000

AKA: gigavps

Quote from: DeathAndTaxes on February 26, 2012, 02:35:33 PM

Quote from: lodcrappo on February 26, 2012, 02:28:10 PM

Quote from: DeathAndTaxes on February 26, 2012, 02:20:56 PM

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.

lodcrappo

hero member

Activity: 616

Merit: 506

Quote from: phr33 on February 26, 2012, 03:43:13 PM

Quote from: lodcrappo on February 26, 2012, 03:31:27 PM

Quote from: phr33 on February 26, 2012, 03:23:04 PM

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...

phr33

full member

Activity: 226

Merit: 100

Quote from: lodcrappo on February 26, 2012, 03:31:27 PM

Quote from: phr33 on February 26, 2012, 03:23:04 PM

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

hero member

Activity: 616

Merit: 506

Quote from: phr33 on February 26, 2012, 03:23:04 PM

Root password is not "changeme"?

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

Topic: BAMT version 0.5 - Easy USB based mining Linux with farm wide management tools - page 73. (Read 324176 times)