Windows Steam in Wine will not launch games

captkrill · 12-12-2013, 02:18 PM

I have Steam for Linux installed and works fine. Using fresh install of 14.1 x64

But I want to run some of the Windows only games from Steam with Wine.

I know that wine works fine with non steam games downloaded from GOG but every time I try and launch an app from steam menu nothing happens except with Age of Empires 2 HD It just sits there preparing first time setup (see attached photo).

Trying to run the one of the games from term outputs this error.

Code:

bash-4.2$ wine "/home/pyrocide/.wine/drive_c/Program Files/Steam/SteamApps/common/FINAL FANTASY VII/FF7_Launcher.exe" 
preloader: Warning: failed to reserve range 00010000-00110000
err:winediag:xrandr12_init_modes Broken NVIDIA RandR detected, falling back to RandR 1.0. Please consider using the Nouveau driver instead.
fixme:advapi:EventRegister {47a9201e-73b0-42ce-9821-7e134361bc6f}, 0x3f005c90, 0x3f03ab30, 0x3f03ab28
fixme:advapi:EventRegister {58a9201e-73b0-42ce-9821-7e134361bc70}, 0x3f005c90, 0x3f03ab68, 0x3f03ab60
fixme:advapi:EventRegister {3fa9201e-73b0-43fe-9821-7e145359bc6f}, 0x3f005c90, 0x3f03aaf8, 0x3f03aaf0
fixme:advapi:EventRegister {1432afee-73b0-42ce-9821-7e134361b433}, 0x3f005c90, 0x3f03aba0, 0x3f03ab98
fixme:advapi:EventRegister {4372afee-73b0-42ce-9821-7e134361b519}, 0x3f005c90, 0x3f03abd8, 0x3f03abd0
p11-kit: couldn't load module: /usr/lib/pkcs11/p11-kit-trust.so: libtasn1.so.6: cannot open shared object file: No such file or directory
p11-kit: couldn't load module: /usr/lib/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory
fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_HANDLE_INFORMATION
fixme:advapi:EventUnregister deadbeef: stub
fixme:advapi:EventUnregister deadbeef: stub
fixme:advapi:EventUnregister deadbeef: stub
fixme:advapi:EventUnregister deadbeef: stub
fixme:advapi:EventUnregister deadbeef: stub
preloader: Warning: failed to reserve range 00010000-00110000
bash-4.2$ err:winediag:xrandr12_init_modes Broken NVIDIA RandR detected, falling back to RandR 1.0. Please consider using the Nouveau driver instead.
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
ILocalize::AddFile() failed to load file "public/steambootstrapper_english.txt".

I have 331.20 NVIDIA driver installed and Nouveau blacklisted. Everything linux native works fine, and a Icewind Dale from GOG in Wine plays correctly.

I tried using Alien's Wine, Slackbuild's Wine as well as the most recent Wine from their site with no dice. Had to use the -no-dwrite quickfix to get steam to run at all. Currently running wine-1.7.8-x86_64-1sg.

Any ideas?

UPDATE: I can get all games to run. Changed Wine to Windows 7 from XP and running from launcher without starting steam with the -no-dwrite quick fix launch option. For whatever reason -no-dwrite kills ability to play games. However, without -no-dwrite you have no access to steam overlay or chat which is essential for some multiplayer

Example of launcher
Working

Code:

env WINEPREFIX="/home/pyrocide/.wine" wine C:\\windows\\command\\start.exe steam://rungameid/228280

Not working

Code:

env WINEPREFIX="/home/pyrocide/.wine" wine C:\\windows\\command\\start.exe -no-dwrite steam://rungameid/228280

Alien Bob · 12-12-2013, 04:42 PM

Looks like at least you are missing the multilib compat32 package "p11-kit-compat32"... maybe more.

Check your multilib installation.

Erio

captkrill · 12-12-2013, 07:51 PM

hmm that's odd. I downloaded the entire multilib directory. Will check again. Thanks!

phenixia2003 · 12-13-2013, 03:22 AM

Hello,

Quote:

Originally Posted by captkrill

I have Steam for Linux installed and works fine. Using fresh install of 14.1 x64

But I want to run some of the Windows only games from Steam with Wine.

I know that wine works fine with non steam games downloaded from GOG but every time I try and launch an app from steam menu nothing happens except with Age of Empires 2 HD It just sits there preparing first time setup (see attached photo).

Trying to run the one of the games from term outputs this error.

Code:

bash-4.2$ wine "/home/pyrocide/.wine/drive_c/Program Files/Steam/SteamApps/common/FINAL FANTASY VII/FF7_Launcher.exe" 
preloader: Warning: failed to reserve range 00010000-00110000
...

To avoid this, which can lead to some troubles, I suggest you to apply this.

Quote:

Originally Posted by captkrill

Code:

...
p11-kit: couldn't load module: /usr/lib/pkcs11/p11-kit-trust.so: libtasn1.so.6: cannot open shared object file: No such file or directory
p11-kit: couldn't load module: /usr/lib/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory
...

Starting from 14.1, p11-kit-compat32 requires libtasn1.so from package libtasn1 which is not in the multilib:

Code:

$ compat32pkg --depends p11-kit-compat32

compat32pkg ver. 1.6.131001 (stable)

[--depends] Started on Fri 13 Dec 2013 08:56:44 AM CET

[--depends]   Inspecting 32-bit binaries from package p11-kit-compat32-0.16.4-x86_64-1compat32
[--depends]     Found 3 32-bit binaries:                        
[--depends]       /usr/bin/32/p11-kit (7 deps.)
[--depends]       /usr/lib/pkcs11/p11-kit-trust.so (6 deps.)
[--depends]       /usr/lib/libp11-kit.so.0.0.0 (5 deps.)
                                             
[--depends]     Found 6 dependencies (0 orphans, 1 unresolved)

[--depends]   5 dependencies are fulfilled by these packages:

	glibc
	glibc-solibs

[--depends]   1 unresolved dependencies : 

	[ Dependency                       ] [ Note                                     ]
	  libtasn1.so.6                        64-bit version in package(s) libtasn1     

[--depends] Ended on Fri 13 Dec 2013 08:56:45 AM CET

Furthermore, it seems the package gnome-keyring is also required to fulfill the dependency /usr/lib/pkcs11/gnome-keyring-pkcs11.so

Try to add the package libtasn1 and gnome-keyring to the multilib to see if that solve your issue. If you use compat32pkg (latest is here) to manage the multilib, you simply have to do the following :

1. Add the lines below in file /etc/compat32pkg/multilib-32bit-packages.lst :

Code:

libtasn1
gnome-keyring

2. Upgrade the 32-bit compatibility layer as below to install the newly added packages :

Code:

compat32pkg --mirror @worldwide-14.1 --upgrade layer-32

compat32pkg ver. 1.6.131001 (stable)

[--upgrade] Started on Fri 13 Dec 2013 09:08:38 AM CET                                             
[--upgrade]   Using mirror ftp://mirrors.kernel.org/slackware/slackware-14.1
[--upgrade]   Local system is Slackware/x86_64 version 14.1
[--upgrade]   Mirrored system is Slackware/i486 version 14.1
[--upgrade]   Slackware-32 packages will be stored into /var/cache/compat32pkg/slackware-32
[--upgrade]   compat32 packages will be stored into /var/cache/compat32pkg/compat-32
[--upgrade]   Configuration file for "layer-32" : /etc/compat32pkg/multilib-32bit-packages.lst version 1.6.131001
[--upgrade]   Trusted external commands : installpkg,upgradepkg,c32pkg-notify-send
                                                                                     
[--upgrade]   3 update(s) were found [ 1 package(s) to upgrade, 2 package(s) to add ] (0,202 sec.)

[--upgrade]   Processing package #1/3: seamonkey-solibs ver. 2.22.1 build 1_slack14.1
[--upgrade]     Package successfully downloaded (/var/cache/compat32pkg/slackware-32/seamonkey-solibs-2.22.1-i486-1_slack14.1.txz)
[--upgrade]     Package converted to format compat32 (/var/cache/compat32pkg/compat-32/seamonkey-solibs-compat32-2.22.1-x86_64-1_slack14.1compat32.txz)
[--upgrade]     Package successfully installed (supersedes ver. 2.22 build 1_slack14.1)         

[--upgrade]   Processing package #2/3: gnome-keyring ver. 3.8.2 build 1
[--upgrade]     Package successfully downloaded (/var/cache/compat32pkg/slackware-32/gnome-keyring-3.8.2-i486-1.txz)
[--upgrade]     Package converted to format compat32 (/var/cache/compat32pkg/compat-32/gnome-keyring-compat32-3.8.2-x86_64-1compat32.txz)
[--upgrade]     Package successfully installed.                                   

[--upgrade]   Processing package #3/3: libtasn1 ver. 3.3 build 1
[--upgrade]     Package successfully downloaded (/var/cache/compat32pkg/slackware-32/libtasn1-3.3-i486-1.txz)
[--upgrade]     Package converted to format compat32 (/var/cache/compat32pkg/compat-32/libtasn1-compat32-3.3-x86_64-1compat32.txz)
[--upgrade]     Package successfully installed.                            

[--upgrade] Ended on Fri 13 Dec 2013 09:09:10 AM CET

Hope this helps.

Cheers

--
SeB

Alien Bob · 12-13-2013, 06:44 AM

Hi phenixia2003

I will update the multilib sources ASAP and add libtasn1 and gnome-keyring to the massconvert32.sh script.
Your compat32pkg does a good job of catching this!

Eric

phenixia2003 · 12-13-2013, 01:31 PM

Hello,

Quote:

Originally Posted by Alien Bob

I will update the multilib sources ASAP and add libtasn1 and gnome-keyring to the massconvert32.sh script.

I updated compat32pkg according to this. The 32-bit layer descriptor for compat32pkg can be updated running :

Code:

compat32pkg --layer-32-config update

Quote:

Originally Posted by Alien Bob

Your compat32pkg does a good job of catching this!

Yes, the --depends option is really useful

to catch unresolved (32-bit) dependencies. Note that the latest compat32pkg (i.e 1.6.131213) fixes some flaws on this point.

Cheers

--
Seb

enorbet · 12-13-2013, 05:39 PM

Greetings - Just a Nod and a Wink -

Nod - It seems, and probably due to Win7 addressing >2G Ram better than XP, that changing Wine to Win7 compatibility can help a lot of modern apps/games run more smoothly.

Wink - I was hesitant to make a permanent change compromising security so instead of editing /etc/sysctl.conf, I used "To make the change from the command line as root: sysctl vm.mmap_min_addr=0" a few weeks ago and though it maybe reduces the number of the dreaded

Warning: failed to reserve range 00010000-00110000

They do still occur and hang or crash the game. So, two things -

1) OP which method did you use and did it cease such errors?

2) Assuming they still occur for you, like they do me, and assuming this is largely a Wine problem since Slackware has no such difficulties reserving this range -

a) isn't the sysctl "fix" a bit of a torn slip bandage?
and
b) isn't there at least a workaround, perhaps in Wine Registry, to tell Wine how to better handle this?

In any case, it is good to see Steam working well and Wine improving, and even better to see such helpful user-created scripts as the compat32pkg. Thanks all.

jtsn · 12-13-2013, 08:53 PM

Quote:

Originally Posted by enorbet

Nod - It seems, and probably due to Win7 addressing >2G Ram better than XP, that changing Wine to Win7 compatibility can help a lot of modern apps/games run more smoothly.

No, it just changes which Windows version number Wine exposes, which in turn changes which APIs applications try to access. Later NT 6 APIs may not be fully implemented in Wine yet, so changing the default Windows version just tends to make your Windows application unstable.

The memory management of Wine applications is completely done by the Linux kernel. The improvements in the Windows 7 code have nothing to with Wine, because Wine doesn't use any proprietary and copyrighted Windows code at all.

Quote:

Wink - I was hesitant to make a permanent change compromising security so instead of editing /etc/sysctl.conf, I used "To make the change from the command line as root: sysctl vm.mmap_min_addr=0" a few weeks ago and though it maybe reduces the number of the dreaded

Warning: failed to reserve range 00010000-00110000

You don't need to give Wine users access to the zero page and make your system vulnerable by kernel null pointer dereference exploits.

Code:

sysctl vm.mmap_min_addr=65536

is enough to fix this problem and it's just 32 KiB below the 98304 default, so the zero page is still protected.

Quote:

a) isn't the sysctl "fix" a bit of a torn slip bandage?
and
b) isn't there at least a workaround, perhaps in Wine Registry, to tell Wine how to better handle this?

Well, there are only two solutions/workarounds regarding this issue:

1. Microsoft changes Windows (and breaks backwards compatibility) to make future Windows applications more compatible with Linux and Wine. (and hell freezes over or so...)

2. You uninstall Wine and stop using Windows applications completely.

Some Windows applications don't need this memory range mapped and still run, some don't. So Wine complains and still executes the application, it may work most of the time. But the existing Windows ABI (which isn't going to change), requires some low-address ranges to be mapped, so there is no way around it, except using a complete virtual machine.

enorbet · 12-13-2013, 09:35 PM

Thank you jtsin.

Well I'm stuck with the bandage then because besides the fact that many games don't run natively in Linux and besides the fact that I prefer to not reboot, there is the issue that many games benefit greatly from superior TCP/IP stack and extreme low latency possible with the Linux kernel. So I'm not uninstalling Wine anytime soon....

Unless.....

Valve just released a complete beta Linux Operating System especially to support Steam and Gaming. I think this is the biggest event for Linux Gaming (and by extension possibly major to Linux as a whole as Gaming is a huge obstacle to would-be migrators and "try 'er outters") since Loki's launch and demise.

Back on main topic - why is it that even after the "fix" it still sometimes fails to reserve this range?

jtsn · 12-15-2013, 06:30 PM

Quote:

Originally Posted by enorbet

Valve just released a complete beta Linux Operating System especially to support Steam and Gaming. I think this is the biggest event for Linux Gaming (and by extension possibly major to Linux as a whole as Gaming is a huge obstacle to would-be migrators and "try 'er outters") since Loki's launch and demise.

The best thing about the whole effort is the Steam Runtime, a fixed binary-compatibility layer for Linux applications. This enables any application to run on any Linux distribution that supports the Steam Runtime without recompiling.

This solves the whole deb/rpm/dependency mess for commercial applications (like games) once and forever.

Quote:

Back on main topic - why is it that even after the "fix" it still sometimes fails to reserve this range?

Dunno. Are you sure, that it is the exact same range above 64 KiB?

enorbet · 12-16-2013, 06:26 AM

Greetings and thanks for the input and Yes.... it is always the same

Code:

 Warning: failed to reserve range 00010000-00110000

It occurs at the startup but the game or app runs anyway and then later it will likely occur again, hanging the game or causing a disconnect from the game server.

jtsn · 12-16-2013, 01:37 PM

And you made sure, that vm.mmap_min_addr is still set at the correct value? Which Slackware kernel are you using?

enorbet · 12-16-2013, 11:46 PM

Greetings
Actually I did not create an "/etc/sysctl.conf" file and instead use the command line

Code:

sysctl vm.mmap_min_addr=0

That Patrick referred to in the similar [Solved] thread. On the rare occasion of a reboot, I just ran it again before launching any wine games. Subsequently I changed the value from "0" to "4096" but I experienced no difference between the two, and the difference between running it and not running it at all is only maybe fewer instances, but that could easily just be chance and expectations projected.

I'll try creating the file and see if that changes anything. I think I may go back to the "0" value since I am the only one with direct access to this box and I am well firewalled and maintained.

To answer your direct inquiry, I am running a custom 3.12.0 kernel. The config is an evolved one from a few years of "make oldconfigs" from the original one created over a rather long and tedious pruning. Don't worry, kernel hacking was not pruned.

Is there a way to see if the command line fix actually made a change?