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

[skyhawk]

where are you guys getting your image from?  I think one of the mirrors must have a corrupt copy.  there is absolutely no reason a machine would be able to boot the image called 0.4 but not the image called 0.5.  they are the same thing.

I don't recall where I got mine from - I think it was the mirror that wasn't asking for donations (I can be kinda selfish)
root:pegasus: sha256 bamt_v0.5c.img
SHA256 (bamt_v0.5c.img) = b3bf88e8ea93b62432f50ce0eed6765019eba18eb6722b576181ea619b92e62b

And I don't think they are entirely the same thing. BAMT 0.4 couldn't find/work with the ethernet on a modern Intel board I tried it on, while BAMT 0.5 works with it fine. I'm not familiar with Debian, but something must have changed in the base system/kernel for that to happen.

[1714767554]

1714767554

[1714767554]

1714767554

[1714767554]

1714767554

[lodcrappo]

where are you guys getting your image from?  I think one of the mirrors must have a corrupt copy.  there is absolutely no reason a machine would be able to boot the image called 0.4 but not the image called 0.5.  they are the same thing.

I don't recall where I got mine from - I think it was the mirror that wasn't asking for donations (I can be kinda selfish)
root:pegasus: sha256 bamt_v0.5c.img
SHA256 (bamt_v0.5c.img) = b3bf88e8ea93b62432f50ce0eed6765019eba18eb6722b576181ea619b92e62b

And I don't think they are entirely the same thing. BAMT 0.4 couldn't find/work with the ethernet on a modern Intel board I tried it on, while BAMT 0.5 works with it fine. I'm not familiar with Debian, but something must have changed in the base system/kernel for that to happen.

checksum is correct.

i have no idea how things are going wrong it your write process, but it seems the only explanation.  

both the image called 0.4 and the images called 0.5 are simply a fat partition and an ext3 partition, with syslinux installed on the fat part and in the mbr.  the same process was used to create both of them (debian live tools).  the same script generated both of them, heck the same machine generated both of them and i used the same usb key to test both of them..   i just don't see how one could possibly work any differently than the other.  the change in label from 0.4 to 0.5 was arbitrary and essentially meaningless.

[skyhawk]

where are you guys getting your image from?  I think one of the mirrors must have a corrupt copy.  there is absolutely no reason a machine would be able to boot the image called 0.4 but not the image called 0.5.  they are the same thing.

I don't recall where I got mine from - I think it was the mirror that wasn't asking for donations (I can be kinda selfish)
root:pegasus: sha256 bamt_v0.5c.img
SHA256 (bamt_v0.5c.img) = b3bf88e8ea93b62432f50ce0eed6765019eba18eb6722b576181ea619b92e62b

And I don't think they are entirely the same thing. BAMT 0.4 couldn't find/work with the ethernet on a modern Intel board I tried it on, while BAMT 0.5 works with it fine. I'm not familiar with Debian, but something must have changed in the base system/kernel for that to happen.

checksum is correct.

i have no idea how things are going wrong it your write process, but it seems the only explanation.  

both the image called 0.4 and the images called 0.5 are simply a fat partition and an ext3 partition, with syslinux installed on the fat part and in the mbr.  the same process was used to create both of them (debian live tools).  the same script generated both of them, heck the same machine generated both of them and i used the same usb key to test both of them..   i just don't see how one could possibly work any differently than the other.  the change in label from 0.4 to 0.5 was arbitrary and essentially meaningless.

I don't spend much time in Linux-land, so I don't think I'll be able to help much. I can only state the following - On the ASUS board in question, BAMT 0.4 USB boots while BAMT 0.5c does not. On a modern Intel motherboard, BAMT 0.4 can't network, while BAMT 0.5c can - the kernel is different.

Googling suggests that SYSLINUX is a flaky critter, not that I can blame it with all the crappy BIOSes it has to deal with. I would look into the following: Has the version of SYSLINUX changed from 0.4 to 0.5c? There may have been a regression that affects certain boards/BIOSes. Have there been changes to the Debian Live Tools? There may have been a regression there too. You say the first partition is FAT, but there are several flavors of FAT. Do the 0.4 and 0.5c images use the same FAT? (FAT16, FAT32, exfat)

Finally, because I don't think I've actually said this yet - Thank you for this awesome tool!

[lodcrappo]

where are you guys getting your image from?  I think one of the mirrors must have a corrupt copy.  there is absolutely no reason a machine would be able to boot the image called 0.4 but not the image called 0.5.  they are the same thing.

I don't recall where I got mine from - I think it was the mirror that wasn't asking for donations (I can be kinda selfish)
root:pegasus: sha256 bamt_v0.5c.img
SHA256 (bamt_v0.5c.img) = b3bf88e8ea93b62432f50ce0eed6765019eba18eb6722b576181ea619b92e62b

And I don't think they are entirely the same thing. BAMT 0.4 couldn't find/work with the ethernet on a modern Intel board I tried it on, while BAMT 0.5 works with it fine. I'm not familiar with Debian, but something must have changed in the base system/kernel for that to happen.

checksum is correct.

i have no idea how things are going wrong it your write process, but it seems the only explanation.  

both the image called 0.4 and the images called 0.5 are simply a fat partition and an ext3 partition, with syslinux installed on the fat part and in the mbr.  the same process was used to create both of them (debian live tools).  the same script generated both of them, heck the same machine generated both of them and i used the same usb key to test both of them..   i just don't see how one could possibly work any differently than the other.  the change in label from 0.4 to 0.5 was arbitrary and essentially meaningless.

I don't spend much time in Linux-land, so I don't think I'll be able to help much. I can only state the following - On the ASUS board in question, BAMT 0.4 USB boots while BAMT 0.5c does not. On a modern Intel motherboard, BAMT 0.4 can't network, while BAMT 0.5c can - the kernel is different.

Googling suggests that SYSLINUX is a flaky critter, not that I can blame it with all the crappy BIOSes it has to deal with. I would look into the following: Has the version of SYSLINUX changed from 0.4 to 0.5c? There may have been a regression that affects certain boards/BIOSes. Have there been changes to the Debian Live Tools? There may have been a regression there too. You say the first partition is FAT, but there are several flavors of FAT. Do the 0.4 and 0.5c images use the same FAT? (FAT16, FAT32, exfat)

Finally, because I don't think I've actually said this yet - Thank you for this awesome tool!

Can you expand on what "can't boot" means?  Does the initial menu with options like safe mode and memory test display?  Are there any error messages?

[skyhawk]

Can you expand on what "can't boot" means?  Does the initial menu with options like safe mode and memory test display?  Are there any error messages?

I see the exact same behavior the original poster describes

I can't boot bamt 0.5 

Bamt 0.4 works fine on two sticks, with bamt 0.5 I get this:

Code:

SYSLINUX 4.02 debia-20101014CHS Copyright (C) 1994-2010 H. Peter Anvin et al
ERROR: No configuration file found
No DEFAULT or UI configuration directive found!
boot:

Googled a bit but none of the solutions worked for me (placing syslinux files somewhere else, burning the image onto the usb stick again and again, trying another usb stick, etc.)
I used Win32 Disk Imager, same one I used with bamt 0.4.

Maybe I'm doing something wrong?

I'm not at all familiar with the SYSLINUX syntax or usage, but near as I can tell it's unable to see anything - it can't see configuration files, kernels or anything else.

[malevolent]

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

[lodcrappo]

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.

[skyhawk]

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.

[malevolent]

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 

[stoppots]

anyone have a link to 0.5c image?

[lodcrappo]

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?

[skyhawk]

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

[lodcrappo]

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?

[skyhawk]

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.

[Inaba]

I'm gonna go out on a limb and guess its's a Gigabyte motherboard?

[lodcrappo]

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. 

[lodcrappo]

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. 

[skyhawk]

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.

[lodcrappo]

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.

[stoppots]

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.