Topic: BAMT version 0.5 - Easy USB based mining Linux with farm wide management tools - page 72. (Read 324169 times)
February 29, 2012, 12:11:43 AM
Watching thanks!
February 29, 2012, 12:05:54 AM
Hell most enterprises today just use DHCP reservations for hundreds of thousands of PCs. You plug the PC in and it always get the exact same IP address forever without any configuration.
Most enterprises utilize DHCP with 1 day (or more) lease periods, but I have not seen an enterprise lease DHCP to a computer forever (except printers/servers, etc), that would just chew up hundreds of thousands of IP's over time as laptop/desktop refreshes occurred and would just be headache from the network perspective unless you continually expanded (or started with a huge) subnet.... either way, it would be very inefficient with IPv4. With a lease time of 3 days or a week, then as long as you plug in once a week, you get the same IP, but if your are out longer than that then you would get a new IP. However, you can prove me wrong, if you go in to the network details of an interface and it says the "lease expires" date is never, or several years out then that basically would be forever.
Once IPv6 becomes mainstream, then it wont be an issue, i could very well see have the same address forever.
However, I got completely sidetracked and off topic (sorry)
My original question is.... I have my wireless card working in BAMT... but it loses the network key on each reboot... anyway to make the key static? I tried wpasupplicant listed here:
http://wiki.debian.org/DebianEeePC/HowTo/Wifi
But that seems to have no effect. Any suggestions?
February 28, 2012, 11:54:50 PM
So, I haven't been worrying about this thread so much, just been announcing updates on the support website.
But, in case anyone isn't paying attention, in the past day or two:
Fix 4
Fixes problem with sending email alerts
Fix 5
Fix for "No protocol specified" error
Fix 6
fixes mining not started at boot, adds logging
Fix 7
add support for bitforce singles
Fix 8
Phoenix2 support
But, in case anyone isn't paying attention, in the past day or two:
Fix 4
Fixes problem with sending email alerts
Fix 5
Fix for "No protocol specified" error
Fix 6
fixes mining not started at boot, adds logging
Fix 7
add support for bitforce singles
Fix 8
Phoenix2 support
February 28, 2012, 04:57:01 PM
How can I set a static ip addres?
The smart way: create a reservation with your DHCP server
The hard way: click the network thingy on the desktop, lower right corner. Edit Connections. Edit your connection as desired. Save.
This. Why do people want to do it the hard way? Today a $29.99 generic router can do DHCP reservations.
Hell most enterprises today just use DHCP reservations for hundreds of thousands of PCs. You plug the PC in and it always get the exact same IP address forever without any configuration.
February 28, 2012, 04:25:24 PM
How can I set a static ip addres?
The smart way: create a reservation with your DHCP server
The hard way: click the network thingy on the desktop, lower right corner. Edit Connections. Edit your connection as desired. Save.
February 28, 2012, 04:25:09 PM
How can I set a static ip addres?
Use your router to set a static ip for the mac address.
Is that the only way? I thought it was possible to set a static ip address in BAMT 0.5?
February 28, 2012, 04:22:52 PM
How can I set a static ip addres?
Use your router to set a static ip for the mac address.
February 28, 2012, 04:11:53 PM
How can I set a static ip addres?
February 28, 2012, 03:26:32 PM
BAMT + cgminer is now working with the BFL single!!!! 
Thanks for lodcrappo for putting up with my linux n00b bull poopy and helping me to get this figured out.
Looks like he made a new fix for 0.5 that takes care of this for all the fellow BAMTer's!
Thanks again lodcrappo!!!
P.S. gpumon and mgpumon do not show any stats on the single.
Thanks for lodcrappo for putting up with my linux n00b bull poopy and helping me to get this figured out.
Looks like he made a new fix for 0.5 that takes care of this for all the fellow BAMTer's!
Thanks again lodcrappo!!!
P.S. gpumon and mgpumon do not show any stats on the single.
February 27, 2012, 09:54:30 PM
Wow. I wish I had switched to using BAMT earlier. It's awesome.
Yeah, once it's setup it just works. I've had a couple rigs go several weeks now without issue.
Remember to donate to keep development going.
February 27, 2012, 09:34:31 PM
Wow. I wish I had switched to using BAMT earlier. It's awesome.
February 27, 2012, 08:33:15 PM
To try and deal with the crazy mess that forum threads seem to lead to, we are going to use a dedicated site for bug tracking and support or feature requests.
http://bamter.org/redmine/projects/bamt
This is also where I will announce new versions, new fixes, and other things that might matter to BAMT users.
I think it will be much more organized than we have been in the past.
February 27, 2012, 08:01:13 PM
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 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?
This happens when one of your GPUs locks up (almost always due to too much overclocking)
you can disable the recovery reboot by setting
detect_defunct: 0
in settings section of bamt.conf
This is documented in the example bamt.conf and https://bitcointalksearch.org/topic/m.755770
However, this will just let your machine sit there with a locked up GPU.
Better to stop making your machine lock up in the first place. Reduce overclocking.
PS - Generally I agree with you that machines should not reboot themselves.
However, after so many people using BAMT have locked up their machines over and over
and refuse to fix their overclocking, it seems the best approach to reduce complaints.
I was coming to that conclusion as well and planned on testing it tonight. Good deal... although I would suggest either a broadcast warning message that explains WHY it's rebooting, possibly a log file containing that info written to persistent storage, and possibly I would say disable it by default and make a note in the config file on enabling it.
In my case, it would have been better for the machine to lock up, since I have no idea which GPU locked up and needs fixin' ... if it was locked up, at least then I could see which GPU caused the error.
You will find in
/live/image/BAMT/CONTROL/ACTIVE/
some files that disable overclocking and explain when/why, if bamt could determine which GPU caused the trouble.
sometimes it cannot.
February 27, 2012, 07:58:56 PM
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 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?
This happens when one of your GPUs locks up (almost always due to too much overclocking)
you can disable the recovery reboot by setting
detect_defunct: 0
in settings section of bamt.conf
This is documented in the example bamt.conf and https://bitcointalksearch.org/topic/m.755770
However, this will just let your machine sit there with a locked up GPU.
Better to stop making your machine lock up in the first place. Reduce overclocking.
PS - Generally I agree with you that machines should not reboot themselves.
However, after so many people using BAMT have locked up their machines over and over
and refuse to fix their overclocking, it seems the best approach to reduce complaints.
I was coming to that conclusion as well and planned on testing it tonight. Good deal... although I would suggest either a broadcast warning message that explains WHY it's rebooting, possibly a log file containing that info written to persistent storage, and possibly I would say disable it by default and make a note in the config file on enabling it.
In my case, it would have been better for the machine to lock up, since I have no idea which GPU locked up and needs fixin' ... if it was locked up, at least then I could see which GPU caused the error.
February 27, 2012, 07:50:29 PM
Yes D&T you are correct. edited.
February 27, 2012, 07:11:22 PM
That was in a root session. Like I said puTTY had no problem.
How is this a root session?
Code:
ssh -X user@
password:
sudo su
This is a root session.
Code:
ssh -x [email protected]
passwrod: root password
there is no sudo su because you are root.
February 27, 2012, 06:54:58 PM
That was in a root session. Like I said puTTY had no problem.
February 27, 2012, 06:09:26 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.
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
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.
ssh as root, and you should not need to do any of that.
February 27, 2012, 06:07:34 PM
lodcrappo,
Would BAMT somehow keep ftdi_sio from writing new devices it finds to the /dev folder?
Thanks,
gigavps
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.
bamt does include ftdi_sio
ls /lib/modules/2.6.32-5-686/kernel/drivers/usb/serial
aircable.ko digi_acceleport.ko io_ti.ko kl5kusb105.ko omninet.ko siemens_mpi.ko usb_wwan.ko
ark3116.ko empeg.ko ipaq.ko kobil_sct.ko opticon.ko sierra.ko visor.ko
belkin_sa.ko ftdi_sio.ko ipw.ko mct_u232.ko option.ko spcp8x5.ko whiteheat.ko
ch341.ko funsoft.ko ir-usb.ko mos7720.ko oti6858.ko symbolserial.ko
cp210x.ko garmin_gps.ko iuu_phoenix.ko mos7840.ko pl2303.ko ti_usb_3410_5052.ko
cyberjack.ko hp4x.ko keyspan.ko moto_modem.ko qcserial.ko usb_debug.ko
cypress_m8.ko io_edgeport.ko keyspan_pda.ko navman.ko safe_serial.ko usbserial.ko
February 27, 2012, 05:56:32 PM
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 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?
This happens when one of your GPUs locks up (almost always due to too much overclocking)
you can disable the recovery reboot by setting
detect_defunct: 0
in settings section of bamt.conf
This is documented in the example bamt.conf and https://bitcointalksearch.org/topic/m.755770
However, this will just let your machine sit there with a locked up GPU.
Better to stop making your machine lock up in the first place. Reduce overclocking.
PS - Generally I agree with you that machines should not reboot themselves.
However, after so many people using BAMT have locked up their machines over and over
and refuse to fix their overclocking, it seems the best approach to reduce complaints.
Jump to: