poclbm error message

[mackminer]

Hi,
Does anyone know what the below message means? It happens when I run poclbm.py from the terminal in Linuxcoin 0.2b. After this error it goes on to show that it is running at <value>Kh/s

/opt/miners/poclbm/BitcoinMiner.py:376: DeprecationWarning: 'enqueue_read_buffer' has been deprecated in version 2011.1. Please use enqueue_copy() instead.
  cl.enqueue_read_buffer(queue, output_buf, output)
127.0.0.1:8332 329213 khash/s/opt/miners/poclbm/BitcoinMiner.py:408: DeprecationWarning: 'enqueue_write_buffer' has been deprecated in version 2011.1. Please use enqueue_copy() instead.
  cl.enqueue_write_buffer(queue, output_buf, output

Any pointer would be greatly appreciated.

Thanks a mill.

[1713526032]

1713526032

[1713526032]

1713526032

[1713526032]

1713526032

[1713526032]

1713526032

[cam02003]

Having this exact same problem.  My pool is not recognizing my work either

[runeks]

A deprecation warning simply means that a certain function (in this case 'enqueue_read_buffer') in - as far as I can tell - PyOpenCL is no longer recommended to use, because it has been superseded by another function (that, eg. ,provides more functionality, fixes a bug), and will stop working after some time. It is displayed so that whoever wrote the program that uses this function can change his or her program to use the new, supported function (in this case 'enqueue_copy').

With regards to the functionality of the program that uses the old, deprecated function, it shouldn't be affected. The old function still works, and the message is only displayed so that the author of the program has a chance to rewrite the program before the function is removed and no longer usable.

In short, tell the author of poclbm.py about this error message

[mackminer]

Just to add a solution in case anyone does search.

This problem turned out to be a permissions issue, The default user is "user" on 0.1b which you would have been running at that time 'second poster', same in 0.2b.

Ideally you should be setting the permission for "user" only but I suspect most people want to see their graphics cards hashing asap, thus focus on mining configuration first.

So to start off, run the following from the terminal "chmod -R 777 /opt/miners"
The above changes permission to read, write and execute for everyone on all files within this folder. The -R option applies the recursive option to the command. (i.e. applies the permission to all sub folders and their files etc. within the specified /opt/miners)

Make sure your wallet is stored on a separate machine (such as your laptop) on a different network. (or VLAN if you've an enterprise grade router)

I'm not sure how important it is that the system is securely locked down from potential attackers (assuming it's on it's own network or VLAN.) The machines are just workstations with one service open, ssh, connecting to the net via NAT.
It's just the wallet you need to be concerned about.

If you have a decent firewall you can lock things down as well. I can only log into my network from one static ip subnet. All the other traffic is going out through NAT. Only services I can access are through ssh, but only from one network, which at any given time is the third network or second network I'm connecting into from.

I don't read email or surf the net from the mining rig and only use reputable software.

 

[Dargo]

Just to add a solution in case anyone does search.

This problem turned out to be a permissions issue, The default user is "user" on 0.1b which you would have been running at that time 'second poster', same in 0.2b.

Ideally you should be setting the permission for "user" only but I suspect most people want to see their graphics cards hashing asap, thus focus on mining configuration first.

So to start off, run the following from the terminal "chmod -R 777 /opt/miners"
The above changes permission to read, write and execute for everyone on all files within this folder. The -R option applies the recursive option to the command. (i.e. applies the permission to all sub folders and their files etc. within the specified /opt/miners)

Make sure your wallet is stored on a separate machine (such as your laptop) on a different network. (or VLAN if you've an enterprise grade router)

I'm not sure how important it is that the system is securely locked down from potential attackers (assuming it's on it's own network or VLAN.) The machines are just workstations with one service open, ssh, connecting to the net via NAT.
It's just the wallet you need to be concerned about.

If you have a decent firewall you can lock things down as well. I can only log into my network from one static ip subnet. All the other traffic is going out through NAT. Only services I can access are through ssh, but only from one network, which at any given time is the third network or second network I'm connecting into from the one I'm sitting connected to directly.

I don't read email or surf the net from the mining rig and only use reputable software.

 

Thanks for this info. I'm wondering, though, to what extent your security recommendations are connected to the terminal command "chmod -R 777 /opt/miners". Is your point that by giving everyone read, write, and execute permission for /opt/miners, this significantly reduces the security of your mining rig? Or are the security suggestions just general "good practice" recommendations that weren't really motivated by the discussion of this command? This is probably a pretty newbish question, but in spite of using Linux for some months now to mine, it's still pretty new to me.

[mackminer]

Just to add a solution in case anyone does search.

This problem turned out to be a permissions issue, The default user is "user" on 0.1b which you would have been running at that time 'second poster', same in 0.2b.

Ideally you should be setting the permission for "user" only but I suspect most people want to see their graphics cards hashing asap, thus focus on mining configuration first.

So to start off, run the following from the terminal "chmod -R 777 /opt/miners"
The above changes permission to read, write and execute for everyone on all files within this folder. The -R option applies the recursive option to the command. (i.e. applies the permission to all sub folders and their files etc. within the specified /opt/miners)

Make sure your wallet is stored on a separate machine (such as your laptop) on a different network. (or VLAN if you've an enterprise grade router)

I'm not sure how important it is that the system is securely locked down from potential attackers (assuming it's on it's own network or VLAN.) The machines are just workstations with one service open, ssh, connecting to the net via NAT.
It's just the wallet you need to be concerned about.

If you have a decent firewall you can lock things down as well. I can only log into my network from one static ip subnet. All the other traffic is going out through NAT. Only services I can access are through ssh, but only from one network, which at any given time is the third network or second network I'm connecting into from the one I'm sitting connected to directly.

I don't read email or surf the net from the mining rig and only use reputable software.

 

Thanks for this info. I'm wondering, though, to what extent your security recommendations are connected to the terminal command "chmod -R 777 /opt/miners". Is your point that by giving everyone read, write, and execute permission for /opt/miners, this significantly reduces the security of your mining rig? Or are the security suggestions just general "good practice" recommendations that weren't really motivated by the discussion of this command? This is probably a pretty newbish question, but in spite of using Linux for some months now to mine, it's still pretty new to me.

I don't really think that security is a major factor that needs to be taken into consideration on mining rigs, (i.e. workstations) assuming the're on their own network subnet. You don't want machines compromised that are on the same network as your personal laptop at home, hence "their own network" or VLAN.

Yes my advice is good practice, the only possible reason I can think of adding it for all users is a compromise on another system account that may not be well secured. If you are sure you have really good passwords set for root and your worker login then just give them permissions.

If someone breaks into your machine via another account then they can't mine using your hardware. I'd also make sure that your config files are only readable by your two accounts though off the top of my head I can't think how useful that would be to an attacker - it's late here, I'm talking about accessing your pool account here to cash your coins out. Deepbit has a preventative measure for this though.

Anyway your really locking things down by making your router only accessible via a work subnet for example or a friends router. Of course with NAT it rules out many security concerns, the only service you need to have open on the firewall is ssh, again though, only accessible from a known network.

[worldinacoin]

I am still facing this error

DeprecationWarning: 'enqueue_read_buffer' has been deprecated in version 2011.1. Please use enqueue_copy() instead.

But the mining pool seems to be recording my workers' processes.

[mackminer]

It's a while since I got over this hurdle so maybe this is a different issue to the one I provided the solution for. Never the less to get up and running you need to chmod these directories and the error you get is similar to above if you haven't applied these.

[runeks]

I am still facing this error

DeprecationWarning: 'enqueue_read_buffer' has been deprecated in version 2011.1. Please use enqueue_copy() instead.

But the mining pool seems to be recording my workers' processes.

As I mentioned in my previous response, it's not an error, it's a warning. Nothing has gone wrong. It's a reminder from the developers of pyopencl to the developers of the phoenix miner, that the phoenix devs should change their code to use the function enqueue_copy() instead of the function enqueue_read_buffer() wherever the latter is used. If they don't, updating pyopencl at some future point might break the phoenix miner code (because it uses a deprecated function, which means a function that will be removed in future versions (of pyopencl)).