Forums

POL uses a 32bits wine build and /usr/lib/i386-linux-gnu is a 32bits folder

Yes but i got the gnome-key from a different file and recreated the file with it (which is where i proably got the 64 bit from)

Wine is looking for the 32bits version of the lib and you are giving it the 64bits one

Well I have been trying to find an alternate keyring but for the love of god its not on the internet and I am trying hard to think of a program (short of an entire OS) that has one.

Try to extract that : http://pkgs.org/ubuntu-10.04/ubuntu-updates-main-i386/gnome-keyring_2.92.92.is.2.30.3-0ubuntu1.1_i386.deb.html (Do not install it)

Try that:

[code=console]echo 0|sudo tee /proc/sys/kernel/yama/ptrace_scope[/code]

I'm getting the same errors with d3, on the same ubuntu version. So it's almost certianly one of the errors shown in the log rather than Blizzard being hopeless. (also my boss on the same network is connecting fine with his non-linux machine)

I'm not sure about the port issue, I can't do much about it here anyway being that it is an office network, however I'm happy to try fixes for the other problem.

I would note that the errors from the gnome key come at the end of the log file, and after the connection has failed. If they were important I'd have expected them as the connection is attempted but that of course depends how the logging works. However with regards to this issue it seems that wine1.5-amd64 correctly connects to the right library so another alternative much be to repackage the wine+diablo patches with the 64bit version rather than just the 32bit version.

Try the command I gave your first

Sir, if you were next to me I'd hug you. It finally work! Would it be ok if I directed people from blizard to here, pointing out this article may solve some of thier problems?

The probleme does definitely not come from Blizzard. I will try to build amd64 patched wine to solve the problem for 64bits users without using the command

Thank you

Thanks, that fix worked for me too (the memory hack / ptrace_scope thingy not the 32bit lib)

I assume this means I have to modify /etc/sysctl.d/10-ptrace.conf and set the value to 0 there so when I reboot it still works (either that or run the ptrace_scope command each time)

Yes that hack I had to use again when my computer restarted so now I need to keep a copy of that code till this all gets sorted out. But, I am not going to complain lol.

What skieler said men, if you were beside me, id treat you.

Try to extract that : http://pkgs.org/ubuntu-10.04/ubuntu-updates-main-i386/gnome-keyring_2.92.92.is.2.30.3-0ubuntu1.1_i386.deb.html (Do not install it)

How do I go about extracting this file?  I downloaded it.

Please read the edit

Try that:

[code=console]echo 0|sudo tee /proc/sys/kernel/yama/ptrace_scope[/code]

Try that:

[code=console]echo 0|sudo tee /proc/sys/kernel/yama/ptrace_scope[/code]

This command really works perfect.

I would just feel more comfortable if i understood what it does_

1) What does that command string?
2) Why do i have to execute it again after reboot, although it has root rights?
3) Why do we want so see a "0" in the command line? Dies "echo 0" have any effect on the part after the "|"?

3) Why do we want so see a "0" in the command line? Dies "echo 0" have any effect on the part after the "|"?

"|" is called the "pipe" in Unix shells. Each program has a standard input and a standard output (a standard error output too), the pipe connects the output of the command to its left to the input of the command to its right (nifty, hey?). If you're interested you can check the manpage of Bash about redirections and pipes.

So here echo "0" output a "0" (and a newline), that's "piped in" the next command; the tee command outputs what it receives on its input to the files named in its arguments and to its standard output (last one being what you see in the terminal as a result of executing this whole command).
sudo is needed because otherwise "tee" would not have the right to write in /proc/sys/kernel/yama/ptrace_scope

1) What does that command string?

/proc is a pseudo filesystem that presents a view of the Linux kernel (settings, run-time statistics...).
This command writes "0" into /proc/sys/kernel/yama/ptrace_scope, which controls what processes may have "debugger"-like rights on other processes (have access to its memory space,...). Default value is "1", that restricts this right to the direct parent of the process only, "0" basically gives debugging rights to all user's processes.
See https://lwn.net/Articles/393010/ for some background history on this security feature.

Why is this necessary here? I don't know, maybe someone knows were this hack comes from...

2) Why do i have to execute it again after reboot, although it has root rights?

Because there's no relation between what is done by root and what is persistent in the system. /proc is just a view upon the realtime state of the kernel, at shutdown everything is lost. The equivalent of above command has to be put in some script evaluated at boot time for the effet to become "persistent", let's say /etc/rc.local; Or simply in /etc/sysctl.conf, that lists changes to apply to /proc at boot time.
However, if you have followed the answer to your question above in details, this would actually be a security concern, as it opens up the system to some malware attacks.
A better permanent fix may be to use setcap to give CAP_SYS_PTRACE capability to the right binary(ies), but again who knows what processes need this "debugging" capability?

Edité par petch

Try that:

[code=console]echo 0|sudo tee /proc/sys/kernel/yama/ptrace_scope[/code]