Topic: BAMT - Easy persistent USB key based linux for dedicated miners/mining farms - page 34. (Read 167479 times)

Whats the output of


If you see something like wlan0 you can use the command line to connect to your wireless router ?

@The--Captain,

I modified the /etc/init.d/networking file as described in your post--thanks for that info. However, while the wired network still works, if I try to go wireless BAMT still does not see the wireless adapter :-/

I must move my two rigs out of the guest bedroom for company starting tomorrow, so I guess I'll have to change over to Linuxcoin, which thankfully does see the wireless adapter.

https://bitcointalksearch.org/topic/m.442617

the debian-live stuff seems to really like to overwrite /etc/network/interfaces at every boot.

there are basically approaches one can take here:

#1 use some file other than /etc/network/interfaces to do your networking (there is nothing magical about that particular file name)
#2 figure out what part of debian-live is overwriting the file, and stop it

I think this has nothing to do with being persistent and more to do with something interfering and overwriting the /etc/network/interfaces. Just a thought does BAMT have any network autoconfigure tools like network-manager installed ?

That's what I'm looking for! Althought I've read the entire 21 pages of this thread I don't recall where exactly your detailed description is. Maybe a link to it?

There aren't hints on how to get your /etc/network/interfaces file to work - there is an extremely detailed description on exactly how to get your /etc/network/interfaces working, by yours truly.

Use scp for file transfer

If your using linux http://www.go2linux.org/scp-linux-command-line-copy-files-over-ssh
or this if your using windows http://winscp.net/eng/index.php

Using:

Or using:

Doesn't seem to make a difference. 1250 memory clock all the time.
I will try harder tomorrow!

https://bitcointalksearch.org/topic/m.469444

Press c when in gpumon

press ctrl-x, y, enter when done.  google 'nano' for more editor help


As answered before, no, wget is for urls.  However there are ways to copy files from windoze shares, google is your friend. 

After almoust 1 hour trying to understand why the I/O error, i suddently remembered i removed the pen drive
Thanks, it worked perfectly and it suits my needs well.

I've just noticed on mgpumon, the reported clocks are 900/1250 instead of 900/300 like i configured.
Should i consider it a bug or, it's definitelly the correct clocks?

EDIT: between 300 and 600 memory clocks there are differences in temperature, hashes and GPU load, although mgpumon doesn't show it i'm pretty sure it it at 300 Mhz!

For one or two machines, editing the conf file over ssh is likely easiest. If you go to a large number of machines, there are options to do pretty much what you said, I believe a lot of people use rsync.

I think you meant, SSH,  Yes you can, but unless you have good knowledge of text editor like VI I suggest you connect using WinSCP (like ftp).

No wget can only be used for HTTP or ftp request.

Finally, posting rights
Once again thanks for such software, been using it on my miner, and will soon move it to the other.

 2 Questions:
-Could i edit bamt.conf from the SSH command window?
-If not:
      wget http://URL.of.bamt##.conf -O /etc/bamt/bamt.conf
Can i use this command, pointing it not to some site, but to a shared folder on my network, example:
      wget 192.168.1.33/bitcoin/bamt/bamt##.conf -O /etc/bamt/bamt.conf

Best regards and keep the good work!

EDIT: why yes, SSH indeed

Excellent. That will teach me to read man pages better. Well, maybe. Thanks for the clarification, I am off to man shutdown now :p

I send all config command I need as a single line / paste, I wget my conf file and pool from a web location.  It's taking me less than a minute to adapt a new BAMT usb to work on a rigGood idea except I bet we're not the only one concerned by this so might as well be able to find data on that elsewhere.  (ULTRA-SPEED (wal-mart) = all dud)I don't know if it write of read,  from a 1min observation, : 20sec , blinked once, 40sec, blink 2, 3sec, blink 1, 5sec, blink 5. (total 10 blink in 1.5min) I would have to make longer monitoring, say filming an hours, but I'm using a rather default setup and don't think I will be the one discovering something that way.

I was being very specific in saying "is it just BAMT ?" meaning as a linux noob I do not always see the line were BAMT stop and Linux start but I though I knew very well when OS stop and Hardware start,  I am often shy asking because I do not expect you to help fixing problems beyond your code.  (I really appreciate you did a few time).

I did have many different problems, some instability were cause by extenders, weird GPU, dual PSU, some GPU don't support low mem clock, I could go ON AND ON...  There is so many sources of trouble adding up when working with completely different hardware on a dozen rig, I think it is understandable I will not bash linux in general at the first sight of a problem.

I think there is more to this story than maybe you are aware of, there have been issues for some time and it just doesn't seem to be a good fit.  Maybe I am wrong.  I only wish to see him have a working mining rig.  If Windows works better for someone, I will of course recommend that they use Windows, anything else would be the wrong advice imho.

The stock 2GB image leaves over 500MB free on a 2gb stick, so this should not be an issue.  I recommend cheap keys for 2 reasons:

#1 - I have some very cheap ones here that work great
#2 - If they don't last long, you're only out a few bucks

Now, if your goal is to find a key that will last forever, or a very long time, then probably the cheap ones are less likely to be what you want (however, there still seems a decent chance they will be fine).   Maybe we should gather stats on which usb keys seem to hold up and put info on the wiki, as we did for motherboards.

BTW when your usb key is blinking, does it indicate whether its reading or writing?  I am concerned that you saw them blinking more than once a minute, maybe something is happening that I don't know about.  However if it's just reading every so often, it may be unavoidable.  Would be good to know, usb keys have limited read cycles too, though much higher than write.



I am not trying to be rude, I am trying to help you find a solution that works for you.  Several times in IRC and here you have mentioned how Windows worked better for you.  Most recently you said:

"I went to linux for stability but I find it to be less reliable than a windows box.  Or is it just BAMT ?"

If you are finding BAMT unreliable, then I encourage you to use whatever *is* reliable.  Life is too short, pick your battles    I say it just isn't going to happen because I think you have done more than enough work trying to sort it out, and we still seem to have some problems.  Maybe I have the wrong impression and all the other issues are sorted out, besides the usb key.  I thought you still had miners locking up and all the various troubles that have been mentioned before.  This is why I recommend to just go with what works.

Yes, I had strange issues the first time I lost an USB stick, too.

This is because much is done via filesystem on linux, so if there is a bad block that holds state files, pipes, (i.e. /tmp contents), or the like, there is a real chance all comes tumbling down, so the best way is probably to re-install it, as you've done.

I would suggest, after fresh install of BAMT, doing all of your customizing, configure it, let it run for an hour or so, check if all is behaving as you like, then shutdown and pull raw image from the stick (vice versa the way you've done it initially). When (and not if, since it's only a matter of time) the stick fails, you still have your configuration and don't have to start over.

As lodcrappo said, probably the best way to further reduce local writes would be switching off munin monitoring or move the datafiles to the network. I will do that as soon as we have a dedicated nfs / munin server in the datacenter.