Your typical linux log files are invar/log/

to read the log files within you will need to use sudo

Examples:

Going off of the dates of the files from withinvar/log/, it looks like the log files that are being used by the system are:
auth.log
crond.log
ddemon.log
errors.log
everything.log
faillog
kernel.log
lastlog
messages.log

So if you know what you're looking for in regards to linux OS, then it should be simple for you to find it.

surely doesn't seem right...

if I had access to a BFL, I'd know more to help ya, sorry.

1) Version 0.2.3
2) Tried that. BFGminer says 2%~ But the minepeon backend says 58%~ (edit: now 87% Some engines even say they get 97.5 % hardware errors)
3) my cgminer is already fully updated since the latest version came with Minepeon 0.2.3

Well its weird. When I screen -r I see bfgminer and cgminer my hardware errors are just around 2%~
But when I check out Minepeon it says the average of both singles is 51%.
With bfgminer some engines even display 98% hardware errors. Not sure whats going on.





Edit:

Isnt this a bit dangerous and only for advanced users?
I don't want to corrupt my entire Minepeon system.
Or is this bug fixed now that it crashed when git pull failed.

having same problem as above, cgminer reports 1 to 2 % HW errors but Peon status page report 40 % HW errors. 0.2.3 with cgminer 3.4.2. could this just be a reporting error? Have 2 bfl 60's hooked up to minepeon and run great. Checked with pool and it doesnt appear I am losing shares.... Dont know what to think about this.

Anyway great job of minepeon!!!! this is a plug and play system!

It does appear that my accepted shares are off by about 1300 per miner, from cgMiner's stats to the stats being displayed on MinePeon's webUI.
Since I'm only running erupters, I could see where something on a larger scale could report much higher.

Going to take a look at the code since I'm awake (and shouldn't be).

If it's any help, my LCDStats screen is outputting the correct figures.

okay, need to go to sleep, I keep screwing with this...

I changed the parameter to the API call to a integer (1) rather than a boolean (true) and now I'm getting a different set of data back that is actually correct.

Gives me something to go off of, I'll look at it more in the morning.

Basically, when passing the command & parameter to the API from PHP, it seems to like an integer to be passed rather than a boolean. Something PHP might be doing odd on the write to the socket, who knows, some times there is some strange shit that pops up.

Rather than

PHP will parse 1 as true (and 0 as false) unless explicitly defined...
ie:

if($foo == 1)() is the same as if($foo == true){} (also if($foo == '1'){} and if($foo == "1")() even though technically the 1 is a string in the last example, PHP doesn't really care), unless you specifically look for a boolean like so, if($foo === true){} or if(is_bool($foo) && $foo == true){}

When I'm passing it to the API socket as true, it seems to not like it for some reason, but it's fine with it as an integer, someone on the CGMiner thread did bring up an interesting thing about SDCard read/writes and I have about 10 SDCards at the house, so I may clone the card and just check that. I'm at work now, if I survive the day with no sleep, I'll try a few things and post more info later today.