Pages:
Author

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

member
Activity: 70
Merit: 10
I wish I could help. I only have 7970s or I would try to troubleshoot it for you. With 7970s I have to upgrade the drivers and I think that's probably what's causing the issue. Have you tried using the AMD Catalyst™ 12.2 Proprietary Linux x86 Display Driver -> http://support.amd.com/us/gpudownload/linux/Pages/radeon_linux.aspx?type=2.4.1&product=2.4.1.3.42&lang=English.


hero member
Activity: 616
Merit: 506
Installed BAMT 0.5c
Install amd-driver-installer-12-2-x86.x86_64.run --force

bamt.conf ->
  cgminer: 1
  cgminer_opts: --api-listen -I 10 -u [whatever] -p [moreso]

  gpu0-3
  disabled: 0
  cgminer: 1

The machine has 4 x 7970

I changed your pearl script because it called with a DISPLAY= :0.0 when it should be calling DISPLAY = :0


my point is that it works correctly with :0.0 for most people.  I am trying to ascertain in what situation it does not work correctly.
is this something that applies to 7970s only?  perhaps because of the different driver you are using in that case?

and probably more importantly, if I change to :0, will it break things for everyone else?  always tricky.

member
Activity: 70
Merit: 10
Installed BAMT 0.5c
Install amd-driver-installer-12-2-x86.x86_64.run --force

bamt.conf ->
  cgminer: 1
  cgminer_opts: --api-listen -I 10 -u [whatever] -p [moreso]

  gpu0-3
  disabled: 0
  cgminer: 1

The machine has 4 x 7970

I changed your pearl script because it called with a DISPLAY= :0.0 when it should be calling DISPLAY = :0
hero member
Activity: 616
Merit: 506
Found the bug that caused cgminer to fail under BAMT. If you find cgminer not launching correctly you need to edit /opt/bamt/common.pl. Find the sub startCGMiner function and change the following line
    $ENV{DISPLAY} = ":0.0";
to
    $ENV{DISPLAY} = ":0";



What version/situation/etc does this apply to? 
member
Activity: 70
Merit: 10
Found the bug that caused cgminer to fail under BAMT. If you find cgminer not launching correctly you need to edit /opt/bamt/common.pl. Find the sub startCGMiner function and change the following line
    $ENV{DISPLAY} = ":0.0";
to
    $ENV{DISPLAY} = ":0";

sr. member
Activity: 271
Merit: 250
anyone have a link to 0.5c image?

there are download links for several mirrors on the download page... how can someone not find that?


Seems http://bamter.org/ was down that day was looking for another source. Trust me when i say I looked.
hero member
Activity: 616
Merit: 506
So would this be a good time to ask how much would be involved in getting BAMT to run with a 4800 series GPU? guiminer/Windows works on the same hardware, but BAMT doesn't.

BAMT's aticonfig sees the card, but clinfo does not. I can populate bamt.conf however I want, BAMT will only ever show "0 GPUs configured".

I'd love a quick fix, but I'm not prepared to sink a whole lot of time into making BAMT work on this machine.

i don't know what a 4800 series card needs that is different from newer cards, and I don't have any to test with here.  at one time a friend of mine was using a 4850 with regular bamt, nothing special needed, but I don't recall what version.

member
Activity: 83
Merit: 10
So would this be a good time to ask how much would be involved in getting BAMT to run with a 4800 series GPU? guiminer/Windows works on the same hardware, but BAMT doesn't.

BAMT's aticonfig sees the card, but clinfo does not. I can populate bamt.conf however I want, BAMT will only ever show "0 GPUs configured".

I'd love a quick fix, but I'm not prepared to sink a whole lot of time into making BAMT work on this machine.
hero member
Activity: 616
Merit: 506
ok.  anybody have a guess as to why a motherboard bios is looking at the type/contents of a partition at all?  I am hesitant to change things until this is understood.
traditionally, the bios simply reads the mbr and has nothing to do with any of the partitions.  why does changing the type make any difference? anybody know?
I think that question would be better directed to the maintainer or support group for SYSLINUX. As I understand it, and I probably should say nothing because I'm not well versed in this, booting is tricky. Booting from USB is much much worse. Until the kernel is loaded and gets off the ground, the very minimal (<512 bytes) mbr code is totally dependent on the BIOS for disk access, and I think most BIOSes actually provide some amount of knowledge of FAT too. This is even worse when dealing with USB, because the BIOS has to "emulate" an IDE drive (and geometry) from the USB device ("Legacy USB support"). Everything I just said also has to interact with the bootloader, in this case SYSLINUX. If any of this hodge-podge of different software layers misfires, the whole thing goes kaput. Motherboard vendors are not well-known for relentlessly pursuing and squashing bugs that don't hurt Windows.

I'd actually be interested in hearing someone familiar with the workings of SYSLINUX comment on my little rant. I think I'm in the right ballpark though.

i guess the answer is "it's complicated".

i'd feel better if I understood the reasons for things here, at least in a general sense, but you're right that this forum isn't the best place to go asking for such info.

I usually just follow the Debian Live project's lead and do things the way they do, as the Debian folks tend to be much smarter than I am.  They use fat16, so I probably should change back in all future images.  As I recall the change to 32 didn't help the guy who asked for it anyway. 

hero member
Activity: 616
Merit: 506
I'm gonna go out on a limb and guess its's a Gigabyte motherboard?

I think the gigabytes just don't boot at all.  Two people recently found that older images would work on their systems but current images would not, and it seems to be because of the FAT partition being fat32 vs fat16. 

Now I wonder if there are some systems that only work with fat32, and some that only work with 16, or if all works with 16 and a few don't work with 32, or what exactly the story is.
Also still don't understand why the BIOS is even looking at the partition type, but obviously it is. 

This stuff is really not in my domain of experience or interest.  Just want to make the image most likely to work for the biggest group and not waste a bunch of time on it. 
legendary
Activity: 1260
Merit: 1000
I'm gonna go out on a limb and guess its's a Gigabyte motherboard?
member
Activity: 83
Merit: 10
ok.  anybody have a guess as to why a motherboard bios is looking at the type/contents of a partition at all?  I am hesitant to change things until this is understood.
traditionally, the bios simply reads the mbr and has nothing to do with any of the partitions.  why does changing the type make any difference? anybody know?
I think that question would be better directed to the maintainer or support group for SYSLINUX. As I understand it, and I probably should say nothing because I'm not well versed in this, booting is tricky. Booting from USB is much much worse. Until the kernel is loaded and gets off the ground, the very minimal (<512 bytes) mbr code is totally dependent on the BIOS for disk access, and I think most BIOSes actually provide some amount of knowledge of FAT too. This is even worse when dealing with USB, because the BIOS has to "emulate" an IDE drive (and geometry) from the USB device ("Legacy USB support"). Everything I just said also has to interact with the bootloader, in this case SYSLINUX. If any of this hodge-podge of different software layers misfires, the whole thing goes kaput. Motherboard vendors are not well-known for relentlessly pursuing and squashing bugs that don't hurt Windows.

I'd actually be interested in hearing someone familiar with the workings of SYSLINUX comment on my little rant. I think I'm in the right ballpark though.
hero member
Activity: 616
Merit: 506
So I am not the only one. I think I even tried two different sources now also tried flashnul (unforrtunately with flashnul no matter how much I tried I couldn't solve the access denied issues). I'll give one last try with the last source and I'll try burning it via a different PC (in case there is a problem with my mobo's usb controller or something).

i looked through the image.  the original "0.4" image used a fat16 partition, but the 0.5 uses a fat32.  this was due to a request from someone who thought it would help their motherboard boot.  as far as i know, it didn't make any difference.

maybe some motherboards can't deal with fat32?  i don't know, but it is the only difference I can find between the two.  i'll upload an image using fat16 later if someone wants to try it.

fat16 image works and boots as expected. As I'm already set-up on this miner's HDD I think I'll just keep it that way for now, but I did test your new image on a USB flashdrive and it works fine. I wrote new imagefile directly from my fileserver with dd if=bamt_v0.5c-fat.img of=/dev/da0 bs=1m

ok.  anybody have a guess as to why a motherboard bios is looking at the type/contents of a partition at all?  I am hesitant to change things until this is understood.
traditionally, the bios simply reads the mbr and has nothing to do with any of the partitions.  why does changing the type make any difference? anybody know?
member
Activity: 83
Merit: 10
So I am not the only one. I think I even tried two different sources now also tried flashnul (unforrtunately with flashnul no matter how much I tried I couldn't solve the access denied issues). I'll give one last try with the last source and I'll try burning it via a different PC (in case there is a problem with my mobo's usb controller or something).

i looked through the image.  the original "0.4" image used a fat16 partition, but the 0.5 uses a fat32.  this was due to a request from someone who thought it would help their motherboard boot.  as far as i know, it didn't make any difference.

maybe some motherboards can't deal with fat32?  i don't know, but it is the only difference I can find between the two.  i'll upload an image using fat16 later if someone wants to try it.

fat16 image works and boots as expected. As I'm already set-up on this miner's HDD I think I'll just keep it that way for now, but I did test your new image on a USB flashdrive and it works fine. I wrote new imagefile directly from my fileserver with dd if=bamt_v0.5c-fat.img of=/dev/da0 bs=1m
hero member
Activity: 616
Merit: 506
anyone have a link to 0.5c image?

there are download links for several mirrors on the download page... how can someone not find that?
sr. member
Activity: 271
Merit: 250
anyone have a link to 0.5c image?
legendary
Activity: 3472
Merit: 1722
otherboards can't deal with fat32?  i don't know, but it is the only difference I can find between the two.  i'll upload an image using fat16 later if someone wants to try it.

Yeah, that'd be great  Wink
member
Activity: 83
Merit: 10
So I am not the only one. I think I even tried two different sources now also tried flashnul (unforrtunately with flashnul no matter how much I tried I couldn't solve the access denied issues). I'll give one last try with the last source and I'll try burning it via a different PC (in case there is a problem with my mobo's usb controller or something).

i looked through the image.  the original "0.4" image used a fat16 partition, but the 0.5 uses a fat32.  this was due to a request from someone who thought it would help their motherboard boot.  as far as i know, it didn't make any difference.

maybe some motherboards can't deal with fat32?  i don't know, but it is the only difference I can find between the two.  i'll upload an image using fat16 later if someone wants to try it.

I'll give it a spin. I think malevolent should too.
hero member
Activity: 616
Merit: 506
So I am not the only one. I think I even tried two different sources now also tried flashnul (unforrtunately with flashnul no matter how much I tried I couldn't solve the access denied issues). I'll give one last try with the last source and I'll try burning it via a different PC (in case there is a problem with my mobo's usb controller or something).

i looked through the image.  the original "0.4" image used a fat16 partition, but the 0.5 uses a fat32.  this was due to a request from someone who thought it would help their motherboard boot.  as far as i know, it didn't make any difference.

maybe some motherboards can't deal with fat32?  i don't know, but it is the only difference I can find between the two.  i'll upload an image using fat16 later if someone wants to try it.
legendary
Activity: 3472
Merit: 1722
So I am not the only one. I think I even tried two different sources now also tried flashnul (unforrtunately with flashnul no matter how much I tried I couldn't solve the access denied issues). I'll give one last try with the last source and I'll try burning it via a different PC (in case there is a problem with my mobo's usb controller or something).
Pages:
Jump to: