# Trials and tribulations with Linuxulator



## VucanRidr (Dec 24, 2021)

I am posting this again with the complete story of my actions in trying to get the Linuxulator to work with GUI apps (like glxgears) or the application I am trying to get working. What follows is a bug report that I filed, which the devs said sounded more like a support request. 

In any case, I am hoping someone can help me to get this working. According to this page, Kerbal is playable in Steam. Do I just need to go out and buy steam, or is that an indicator that the GOG version of the same code should work on FreeBSD and I am just not going about it right?

I have tried several times and several ways to run the GOG version of Kerbal Space Program on the Linuxulator. I have read the documentation several times and it feels like there are missing steps that are not in the documentation. I have tried the following:

* Installed the entirety of the linux-c7 packages and attempted to run the app, and the binary seems to hang in the terminal window, but the graphics never appear, and I am unable to ctrl-c out of it.

* Installed Ubuntu 20.04 in /compat/ubuntu, installed my username with the same UID/GID as my userid as on the FreeBSD side, and had the same behavior as with linux-c7.

* Installed Debian Bullseye, then converted it to Devuan Chimaera (to eliminate the issue of systemd) in /compat/devuan, set up user in the same way as ubuntu above. Same result.

I currently have /compat/linux (c7) and /compat/devuan.

I also set up an ubuntu jail as well as a devuan jail. On both of those, I installed Kerbal in the jail, when I try to run glxgears or the KSP binary, I get:

storm@brahms:/var/log$ glxgears
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  151 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Value in failed request:  0x0
  Serial number of failed request:  31
  Current serial number in output stream:  32

I posted the jail issue to the forum, and was told that ssh X forwarding does not support 3d graphics through the tunnel. But why can I not get either glxgears or kerbal to run from within

Can 3d graphics be run through the linuxulator? If so, how can I get kerbal tp run? The Linux box I am running it on currently has a mobile i7, 16GB of RAM and Intel graphics. My FreeBSD box has a full i7, 32GB of RAM and an nVidia GTX780Ti.


----------



## shkhln (Dec 25, 2021)

VucanRidr said:


> In any case, I am hoping someone can help me to get this working. According to this page, Kerbal is playable in Steam. Do I just need to go out and buy steam, or is that an indicator that the GOG version of the same code should work on FreeBSD and I am just not going about it right?


What do you think? What does the third cell in the row say?


----------



## VucanRidr (Dec 26, 2021)

shkhln said:


> What do you think? What does the third cell in the row say?


I know, it says to set launch options to LD_PRELOAD=${LD_PRELOAD}:monofix.so %command%

Actually, I tried doing
LD_PRELOAD=${LD_PRELOAD}:monofix.so ./KSP.x86_64

The result:

```
storm@defiant:~/GOG Games/Kerbal Space Program/game$ LD_PRELOAD=${LD_PRELOAD}:monofix.so ./KSP.x86_64
ERROR: ld.so: object 'monofix.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
Set current directory to /home/storm/GOG Games/Kerbal Space Program/game
Found path: /home/storm/GOG Games/Kerbal Space Program/game/KSP.x86_64
```
...And then the window hung.

I have linux-steam-utils-20211006 installed, and I also created a copy of monofix.so within the devuan jail in /usr/local/steam-utils/lib64/monofix/monofix.so

I'm probably not implementing it correctly, got a suggestion?

Thanks and Merry Christmas.
--vr


----------



## shkhln (Dec 26, 2021)

`LD_PRELOAD=whatever.so` only works if whatever.so is already in the search path, otherwise this should be `LD_PRELOAD=/full/path/to/whatever.so`.


----------



## VucanRidr (Dec 27, 2021)

shkhln said:


> `LD_PRELOAD=whatever.so` only works if whatever.so is already in the search path, otherwise this should be `LD_PRELOAD=/full/path/to/whatever.so`.


Okay, makes sense. So that got rid of the monofix.so ignored line, however, it still tries to start the program and just hangs there in the linuxulator. If I try to start it in FreeBSD, the screen flashes like it is getting ready to try and start, but then it gives me an Abort Trap.


----------



## grahamperrin@ (Dec 27, 2021)

VucanRidr said:


> … hangs …



Is there any sense of these hangs affecting anything other than Linuxulator? I mean, for example, any impact on task switching in a desktop environment?


----------



## VucanRidr (Dec 27, 2021)

grahamperrin said:


> Is there any sense of these hangs affecting anything other than Linuxulator? I mean, for example, any impact on task switching in a desktop environment?


No sir. I cannot control c out of that Konsole session, so I end up having to kill the tab, but other than that, no side effects that I have noticed.


----------



## shkhln (Dec 30, 2021)

See if there is anything useful in the ~/.config/unity3d/ dir.


----------



## VucanRidr (Dec 31, 2021)

shkhln said:


> See if there is anything useful in the ~/.config/unity3d/ dir.


I posted the Player.log file at https://bsd.to/QfjO, and the prefs file is at https://bsd.to/anHu


----------



## shkhln (Dec 31, 2021)

VucanRidr said:


> I posted the Player.log file at https://bsd.to/QfjO, and the prefs file is at https://bsd.to/anHu





> Assertion 'pthread_mutex_unlock(&m->mutex) == 0' failed at pulsecore/mutex-posix.c:108, function pa_mutex_unlock(). Aborting.


The workaround linux-steam-utils employs for that issue is basically a noop libpulse stub. Set LD_LIBRARY_PATH=/usr/local/steam-utils/lib64/fakepulse to use it.


----------



## VucanRidr (Jan 26, 2022)

Sorry for the delay on this, I am recovering from covid. I tried this combination on the devuan chroot:
$ LD_PRELOAD=${LD_PRELOAD}:/usr/local/steam-utils/lib64/monofix/monofix.so  
$ LD_LIBRARY_PATH=/usr/local/steam-utils/lib64/fakepulse
$ ./KSP.x86_64  
Set current directory to /home/storm/GOG Games/Kerbal Space Program/game
Found path: /home/storm/GOG Games/Kerbal Space Program/game/KSP.x86_64

and the tab hangs, as it has before. 

If I do the same thing in FreeBSD itself, 
$ LD_PRELOAD=${LD_PRELOAD}:/usr/local/steam-utils/lib64/monofix/monofix.so  
$ LD_LIBRARY_PATH=/usr/local/steam-utils/lib64/fakepulse
$ ./KSP.x86_64

The taskbar flickers like the app is getting ready to start, then goes back to normal.


----------



## shkhln (Jan 27, 2022)

It's `export LD_PRELOAD` and `export LD_LIBRARY_PATH`.


----------



## VucanRidr (Jan 27, 2022)

Okay, I did this. In the chroot, it still hung. In FreeBSD, kept getting 


```
ld-elf.so.1: Shared object "libdl.so.2" not found, required by "monofix.so"
```

So running from FreeBSD is apparently contraindicated.


----------



## grahamperrin@ (Jan 29, 2022)

```
% pkg provides libdl.so.2
Name    : linux_base-c7-7.9.2009
Desc    : Base set of packages needed in Linux mode (Linux CentOS 7.9.2009)
Repo    : FreeBSD
Filename: compat/linux/usr/lib64/libdl.so.2
          compat/linux/usr/lib/libdl.so.2
%
```

That's probably no help, in that you already previously 



VucanRidr said:


> … Installed the entirety of the linux-c7 packages …


----------



## shkhln (Jan 29, 2022)

VucanRidr said:


> ```
> ld-elf.so.1: Shared object "libdl.so.2" not found, required by "monofix.so"
> ```


ld-elf.so.1 is the name of FreeBSD's dynamic linker, which means you are (accidentally?) trying to run a FreeBSD executable with a Linux lib (monofix.so) in LD_PRELOAD. This is obviously not a good idea. You should only use that LD_PRELOAD with KSP.x86_64.


----------

