Pages:
Author

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

member
Activity: 83
Merit: 10

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  Sad

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.
hero member
Activity: 616
Merit: 506

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?
member
Activity: 83
Merit: 10

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!
hero member
Activity: 616
Merit: 506

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.




member
Activity: 83
Merit: 10

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.
hero member
Activity: 616
Merit: 506
something is seriously wrong with your image or your usb key.

suggest to download again.

I think my keys are fine, tried 3, of two different brands, and tried burning the img several times. Also, the was no problem with 0.4.

I'll download again from a different source and report once I try.

there is no difference in boot between "0.4" and "0.5".  There is very little difference in anything between the last 0.4 fix and the first 0.5 image.

the numbering sequence change was simply an arbitrary decision designed to try and make a clean start with documentation and other administrative things.
from a code perspective, "version 0.4" and "version 0.5" means basically nothing, I just decided instead of doing fix #37 for "0.4" we would call it 0.5 fix 1.

I had the exact same problem - machine running fine on 0.4, refused to boot 0.5 for love or money. I eventually just wrote the image directly onto the otherwise-unused HDD in the machine and it boots off that. It's an old ASUS board, and one of the many reasons I don't buy ASUS boards anymore.

If you're not familiar with Linux/Unix this can be a bit tricky. Burn something like SystemRescueCD and boot off that, then plug in your flashed USB drive. You need to determine your flashdrive and HDD devices. Run ls -l /dev/disk/by-id This output shows the identifiers of your storage hardware and what devices they link to. I'm going to assume your HDD is /dev/sda and your flashdrive is /dev/sdb.

It should go without saying this operation will make the existing contents of the HDD unusable, without substantial effort to recover them. If you want to properly wipe the HDD first, run shred -n 0 /dev/sda

Run dd if=/dev/sdb of=/dev/sda bs=1m Be sure to ignore partition numbers - no /dev/sda1 or whatever. You want to write the entire contents of the image directly to the first sector of the HDD.

Flashing the image file itself from somewhere is more efficient and faster, but more complicated and hard to explain. I mounted an SMB share from my fileserver and flashed the imagefile with dd if=/mnt/server/bitcoin/BAMT/bamt_v0.5c.img of=/dev/sda bs=1m


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.
member
Activity: 83
Merit: 10
something is seriously wrong with your image or your usb key.

suggest to download again.

I think my keys are fine, tried 3, of two different brands, and tried burning the img several times. Also, the was no problem with 0.4.

I'll download again from a different source and report once I try.

there is no difference in boot between "0.4" and "0.5".  There is very little difference in anything between the last 0.4 fix and the first 0.5 image.

the numbering sequence change was simply an arbitrary decision designed to try and make a clean start with documentation and other administrative things.
from a code perspective, "version 0.4" and "version 0.5" means basically nothing, I just decided instead of doing fix #37 for "0.4" we would call it 0.5 fix 1.

I had the exact same problem - machine running fine on 0.4, refused to boot 0.5 for love or money. I eventually just wrote the image directly onto the otherwise-unused HDD in the machine and it boots off that. It's an old ASUS board, and one of the many reasons I don't buy ASUS boards anymore.

If you're not familiar with Linux/Unix this can be a bit tricky. Burn something like SystemRescueCD and boot off that, then plug in your flashed USB drive. You need to determine your flashdrive and HDD devices. Run ls -l /dev/disk/by-id This output shows the identifiers of your storage hardware and what devices they link to. I'm going to assume your HDD is /dev/sda and your flashdrive is /dev/sdb.

It should go without saying this operation will make the existing contents of the HDD unusable, without substantial effort to recover them. If you want to properly wipe the HDD first, run shred -n 0 /dev/sda

Run dd if=/dev/sdb of=/dev/sda bs=1m Be sure to ignore partition numbers - no /dev/sda1 or whatever. You want to write the entire contents of the image directly to the first sector of the HDD.

Flashing the image file itself from somewhere is more efficient and faster, but more complicated and hard to explain. I mounted an SMB share from my fileserver and flashed the imagefile with dd if=/mnt/server/bitcoin/BAMT/bamt_v0.5c.img of=/dev/sda bs=1m
full member
Activity: 164
Merit: 100
lodcrappo,

Where is the mgpumon.css file? I searched the who thing and can't find it.
member
Activity: 114
Merit: 10
Tried that already, but that's not possible. I have three options: UMA, Sideport, UMA+Sideport -> no "disable". Any more ideas?

Greetz
NetworkerZ
yxt
legendary
Activity: 3528
Merit: 1116
member
Activity: 114
Merit: 10
Hiho!

Flashed all my cards to unlocked BIOS versions. BAMT is running fine on 2 of my 3 rigs. The third rig doen't start mining. There is no entry in the messages or bamt.log I'm not sure what to do now, but perhaps BAMT has a problem with the onboard GPU HD 4200?!? I don't want to use it, I haven't configured, etc. But it is recogniced by the driver. Has someone an idea?

THX
NetworkerZ
hero member
Activity: 616
Merit: 506

Ok, will try.  I underclock my cards while I sleep for courtesy for my roommate.  Is there any way to find out which card it is?


Unfortunately no.  When a GPU is put outside of it's normal operating conditions and then locks up, all bets are off.  Something hung on GPU 2 might cause GPU 0 not to respond, or vice versa.  One GPU might lock up the entire bus.  There is no definitive way to tell which GPU "caused" the lock up.

In many cases, you will find that the problem is not as simple as one card being set too high or low, but that your system cannot remain stable due to the combined effects of several GPUs being slightly out of tolerance.  Changing the values of any one GPU might change the problem or even make it go away, but that doesn't mean that GPU was necessarily "bad" or the cause of the issue. 

Manually setting clocks is basically begging for strange system behaviors.  Don't be surprised when they happen Smiley
sr. member
Activity: 369
Merit: 250

when a GPU is locked up, all processes that attempt to communicate with it tend to hang.

a mother that has been around for 450 seconds is a sure sign of a locked up GPU.

run cards at stock, and problems very likely disappear.  if not, you've got defective hardware (or really, really poor cooling).


Ok, will try.  I underclock my cards while I sleep for courtesy for my roommate.  Is there any way to find out which card it is?

I clock my 5970 down to 675/300 @ .95v
All temps are kept between 60 and 70
hero member
Activity: 616
Merit: 506


I also get this:
Code:
root@rig-1:~# mother -v
mother starts (452 seconds since last run)
Another mother is already running. Bail out!

when a GPU is locked up, all processes that attempt to communicate with it tend to hang.

a mother that has been around for 450 seconds is a sure sign of a locked up GPU.

run cards at stock, and problems very likely disappear.  if not, you've got defective hardware (or really, really poor cooling).


hero member
Activity: 616
Merit: 506
Is there any way to check logs to see why my system hung?  Sometimes I need to cycle it, because it stops mining.  Its like it just freezes :/

reduce your overclocking

Its crazy underclocked though :/

so reduce the underclocking.  quit breaking it by messing with the clocks, basically.
sr. member
Activity: 369
Merit: 250
Is there any way to check logs to see why my system hung?  Sometimes I need to cycle it, because it stops mining.  Its like it just freezes :/

reduce your overclocking

Its crazy underclocked though :/
hero member
Activity: 616
Merit: 506
Is there any way to check logs to see why my system hung?  Sometimes I need to cycle it, because it stops mining.  Its like it just freezes :/

reduce your overclocking
sr. member
Activity: 369
Merit: 250
Is there any way to check logs to see why my system hung?  Sometimes I need to cycle it, because it stops mining.  Its like it just freezes :/

I also get this:
Code:
root@rig-1:~# mother -v
mother starts (452 seconds since last run)
Another mother is already running. Bail out!
hero member
Activity: 616
Merit: 506
Just upgraded to 0.5c today, working great!

However, I just stuck my sapphire 6870 in and I can't adjust the clocks unless I go into atitweak.  Also, My voltage is rock solid.  I have no idea how to lower it o.o

6870s change clocks fine here, but voltage is not possible.
hero member
Activity: 626
Merit: 500
Mining since May 2011.
Just upgraded to 0.5c today, working great!

However, I just stuck my sapphire 6870 in and I can't adjust the clocks unless I go into atitweak.  Also, My voltage is rock solid.  I have no idea how to lower it o.o

I believe on 6xxx cards you'd have to mess with the BIOS. I have many 5xxx cards that OC without issue, all settings. My 6xxx ones though I can only change the clock and fan, memory and voltage are locked. YMMV it seems.
Pages:
Jump to: