Trials and tribulations with Linuxulator

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.
 
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?
 
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:
Code:
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
 
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.
 
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.
 
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.
 
Okay, I did this. In the chroot, it still hung. In FreeBSD, kept getting

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

So running from FreeBSD is apparently contraindicated.
 
Code:
% 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

… Installed the entirety of the linux-c7 packages …
 
Code:
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.
 
Back
Top