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

I have been looking at network boot.  it would not be too difficult.  the debian live tools can generate a netboot image from the same source that makes regular bamt. 

also, found some additional writes to disk that are eliminated in upcoming version, that will help keys live longer.

I sorta remember this being the case but it's been awhile. Can you tell me the hash rates between the two? Does it effect the 5830s also? Also if you successfully swap back to 2.1 let us know how it works out. =)

Donation sent too. =)

Has anyone ever tried to setup a lan boot server to host the images for each rig? The cheap ass flash drives I bought are dying left right and center. I'd also like to remotely reset the image for a rig if it was running into issues. I have a remote reboot setup already when it locks up, but if it's loading the same image that doesn't always fix the problem. I'd like to have one machine with a HD (maybe raid 1) to host the 10 rig images and have everything boot from LAN. I've found the fastest fix is just swap in a new flash drive and that fixes 99% of the problems I've run into. I'm not sure if it's the flash drive dying or something being corrupted, it's not worth figuring out since it takes 15 seconds to swap the flash drive. But if it's a remote farm that is a little more trouble. =)

Some rigs I switched to laptop HDs I had lying around and that works fine. I'm just wondering if anyone has gone a step further to help manage remote farms.  If no one else has done it does anyone know how hard this would be to setup? If it's not horribly difficult I'll start a bounty. =)

Fix #20, containing a super charged version of Phoenix 1.7.4 is available now via the BAMT fixer.

As root,

/opt/bamt/fixer


Several additional improvements are coming in the next few days...

Ah, I see. Thanks, will try.

No.  There are about a dozen bugfixes and new feature packages you are missing, including the bugfix that will almost certainly solve your problem.

As root, run:

/opt/bamt/fixer

more details here = http://aaronwolfe.com/bamt/download.html

I'm using BAMT 0.4b, is that what you meant by fixes?

lodcrappo,

upping the init delay to 60 did the trick!

Thanks!

Sorry.. linux newb.  Where would I see or find those screen sessions?
I have seen a message that states ""Starting mining processes...: mineNo protocol specified"

But a restart starts the miners fine, so I believe my bamt.conf and pools are correct.


I'll try to up the init_delay to 60 and post a result.

Thanks!

probably not, linux isn't as silly as windows in general. OTOH I've never tried it, so who knows.  You could remove 2.4 if it causes some problem.  Google around for how to install the sdk on debian, thats what you need to do.

So the two would not conflict like on Winblows, right ?

Just install the version you prefer, same as you would do on any linux box.

Any idea about how I might replace that with 2.1 because 5870s + 2.1 = rocks while 5870s + 2.4 = meh.

Thanks !

Updated the FAQ with version numbers for various things

https://github.com/aaronwolfe/Big-A-Miner-Thing/wiki/Faq

2.4

What SDK does this use ? 2.1 or 2.4 ?

Thank you !

THE OCTOBAMT CHALLENGE

Spent some time trying to help LittleDuke get 8 GPUs working in bamt.  Also reviewed this thread and a found everyone else who has tried 8 got the same results we did:  It doesn't work.

7 GPUs = totally fine
8 GPUs = the ati driver crashes, machine locks up, game over

Pretty sure more than 8 is impossible on any linux box, but it would be nice to get that 8th slot working for people who cram 4 5970s into a box etc.

I don't have any machines anything like that, so testing things is quite difficult here.  If you do have a rig that can support 8 GPUs, I hearby invite you to enter the first annual OCTOBAMT challenge!

The rules are simple:  Using any tool or technique, get BAMT working with 8 GPUs.  The solution must be something we can apply to the standard BAMT image without reducing the existing BAMT functionality, otherwise anything goes.

The first person to complete the challenge will be awarded a fantastic prize package which includes unspecified items of practically undefinable value.  You will be as a god among men, celebrated and feared throughout the land.  Don't let this amazing opportunity pass you by.

Hints:
My suspicion is that the drivers we use are just broken.  Limited experiments with other versions have revealed that certain versions, such as 10.11 and 11.12 behave differently than our version (11.6 iirc).  Other versions, 11.7-11.10 seem to lock up just the same as 11.6.
However, 10.11 and 11.12 seem to introduce their own problems, which may or may not be something that can be resolved.

Yes, it should.  what is showing in the mining screen sessions after a boot up, or do they even exist yet?

There are some time delays in the init process that are there to let X get started and ready before the GPUs fire off.  If your system just takes longer to get X running than the default delay, then the miners are starting too soon and will fail.

To see if that is what is happening, try adjusting these to be longer:

  # at boot, how long to wait for X to start (seconds)
  start_mining_init_delay: 20

  # delay in between starting individual GPUs (seconds)
  start_mining_miner_delay: 3

Maybe try 60 seconds on the  start_mining_init_delay just to be sure, and if that fixes it then reduce until it breaks again.  

pretty much everything in bamt only works as root.  don't even bother with sudo, login as root from the start (or start a "root terminal", not regular one, from gui.  but don't use the gui, it sucks.  use ssh).

yeah, yeah.. common belief is that it's "bad" to be root on a normal *nix system.  BAMT is not a normal system.  It is designed to be a single user (or preferably 0 user) environment.  Many of the things you want to do on a mining rig always require root access anyway.  Most (if not all) of the reasons you shouldn't be root do not apply, as this is not a general purpose system.  So.. learn to live as root when in BAMT.

Your connect and disconnect problem sounds like you have one of the below:

#1 pool_timeout is set too low.  If a share is not accepted within this time period (specified in seconds) then BAMT will kill phoenix and restart it with the next pool URL (or the same one if you have specified only one).

#2 you've specified a max shares or a low max time value for this pool in the pools file.  Specifying max shares will cause BAMT to always kill and move to next url after that # of shares are accepted.  Specifying a low max time value is just like setting pool_timeout too low.

see https://github.com/aaronwolfe/Big-A-Miner-Thing/wiki/Using-bamt

Sounds like you might not have updated either.  See previous post.

PS sometimes X chooses a different GPU or screen to put it's output on than Linux chooses to use for the console.  don't ask me why.  best to just not connect a screen at all, use ssh.