My latest problem with BAMT - a rig doesn't mine, I can't putty in, and when I bring up a local terminal and try atitweak -s, it tells me about an 'invalid MIT-MAGIC-COOKIE'.
Having waded through pages of forum posts, a temporary fix seems to be to delete ~user/.Xauthority and ~root/.Xauthority and then reboot. But I have to keep going in manually to do this, and it only works til the next hangup maybe half a day later.
Could somebody check my understanding of this? I *think* that it basically only happens when I have to power off the system at the switch... then the problem appears when I boot it up again. But it doesn't ALWAYS seem to happen. And it doesn't happen if the system was mining successfully and I power it down the way it should be done, with a shutdown or coldreboot command.
I read the following from lodcrappo responding to another guy whose problem also seemed to lie with Xauthority somehow:
Here is what happens at boot..
1 - normal linux stuff
2 - x windows config blown away
3 - ati device detection -> generate new x win config
4a - x starts in one thread
4b - mine_start starts in another thread, sleeps for start_delay
5 - X finally gets going
6 - default user logs in automatically to x session
7 - mine_start script runs xauth + to make the X server allow connections
now, in root's .bashrc there is a command: xauth merge /home/user/.Xauthority
this runs when you log in as root. it gives root the ability to talk to the X server.
however, if you log in via ssh before step 6 completes, the .Xauthority file isn't there yet and you get no joy.
or if step 7 happens before step 5, you'll get no joy.
some USB keys are much, much slower than others. same with cpu, etc. having more GPUs means step 3 can take much longer. some GPUs seem to make step 4a/5 take a really long time if no monitor is attached. there are many variables here. since the process splits in step 4, there isn't a strong tie between them and things can get out of order, or you can just be in a rush and logging in via ssh too soon.
Okay I think I understand all that. And I suppose what might be happening is that 'step 7 happens before step 5'. BUT, a quick perusal of the start_mining script suggests that this *cannot* happen, as mine_start won't run 'xauth +' until it sees the X server is running.
Also, why the difference in behaviour between the two different ways of rebooting?
Basically how I do stop this shit happening all the time? Or at least shove some extra perl in to detect it and do something clever?