Web lists-archives.com

Re: Wine doesn't start




On 2018-03-28 at 15:44, Markus Grunwald wrote:

> Hello,
> 
> to play some old games, I wanted to start wine, but it always fails with
> errors like that in the attached gna.txt :(
> 
> Not even winecfg is starting (I created gna.txt with starting winecfg).
> 
> It used to work so well a while ago...
> 
> 
> That's what I have installed (debian testing, upgraded today):
> 
>  % dpkg -l wine\* | egrep '^ii'
> ii  wine             3.0-1          all          Windows API
> implementation - standard suite
> ii  wine32:i386      3.0-1          i386         Windows API
> implementation - 32-bit binary loader
> ii  wine64           3.0-1          amd64        Windows API
> implementation - 64-bit binary loader
> ii  winetricks       0.0+20180217-1 all          package manager for
> Wine to install software easily
> 
> 
> 
> Can you help me with that, please?

Looking online, the large majority of places where "failed to map
segment from shared object" occurs outside of this post itself seem to
have an additional explanatory comment appended to it. In the log you
attached, no such comment appears to be present.

I haven't found much of anything hinting at what might lead to that
situation. Possible hints I have found for other causes of that
"umbrella" message include:

* ulimit too low. (Results in "Cannot allocate memory" explanatory comment.)

* One or more of the executable files which the program is trying to
load (here, 'version.dll.so') is stored on a filesystem which is mounted
noexec. (Results in "Operation not permitted" explanatory comment. Since
the paths indicate that this is apparently being loaded from under
/usr/lib/i386-linux-gnu/, it doesn't seem very likely that noexec could
be in play.)

* The relevant executable file does not have the execute bit set. (Not
clear what explanatory comment results. I don't think this should apply
for .dll.so files like this one; certainly the analogous file for my
Wine install doesn't have that bit set.)

* SELinux is blocking the file from being loaded. (Results in
"Permission denied" explanatory comment. Other LSMs, such as AppArmor,
might presumably result in the same problem.)

There's also a semi-weird case where access to local files was mediated
by ActiveDirectory authentication, and the environment where the program
was being launched wasn't retaining the environment variable which
provided the username against which the authentication would be done, so
the program couldn't access local files. That seems unlikely to apply,
however.

I don't know whether any of these may bear at all on your environment,
but at least they might give you places to start looking...

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

Attachment: signature.asc
Description: OpenPGP digital signature