Hi,
I'm trying to run Oolite in a Docker container (don't ask).
I'm using Ubuntu as my base image.
I have installed the 1.90 release into the image, but when I try to run it I keep getting tripped up by missing shared libs. The latest one has me stumped, because it's missing ALSA libs, which according to Google is part of libasound2, and I've installed that already.
Can anyone point me to a full list of dependencies I need to install into the image?
Oolite in a Docker container
Moderators: winston, another_commander, Getafix
- Getafix
- Quite Grand Sub-Admiral
- Posts: 979
- Joined: Tue Apr 01, 2008 12:55 pm
- Location: A small ice asteroid, orbiting Oresrati in Galaxy 8 (a.k.a. northwest Armorica).
- Contact:
Re: Oolite in a Docker container
Hi Crush,
I will update this post later today with a list of dependencies. However Oolite is pretty self contained bundling the libs needed and only core libs are left to the O/S to deliver.
In the meantime let's gather some info. Not much of a Docker savvy myself so I'm googling myself around to see if I can help.
Let's try to understand your environment first.
What kind of Ubuntu do you have? (ubuntu desktop / ubuntu server, release number)
Is Ubuntu installed on a VM?
Do you have any other application non-dockerized manifesting sound? What about the dockerized apps?
Your Oolite installation is under
Have you tried or can you try non-dockerized execution of Oolite? (to enter the dockerized approach probably you can't but questions are cheap)
Could you share the docker command line you execute trying to start Oolite?
Do you remember the missing libs in the order they were requested?
What did you do to proceed further until you reached the ALSA impasse?
That's it for starters.
I will update this post later today with a list of dependencies. However Oolite is pretty self contained bundling the libs needed and only core libs are left to the O/S to deliver.
In the meantime let's gather some info. Not much of a Docker savvy myself so I'm googling myself around to see if I can help.
Let's try to understand your environment first.
What kind of Ubuntu do you have? (ubuntu desktop / ubuntu server, release number)
Is Ubuntu installed on a VM?
Do you have any other application non-dockerized manifesting sound? What about the dockerized apps?
Your Oolite installation is under
~/GNUstep/Applications/
or under /opt/
?Have you tried or can you try non-dockerized execution of Oolite? (to enter the dockerized approach probably you can't but questions are cheap)
Could you share the docker command line you execute trying to start Oolite?
Do you remember the missing libs in the order they were requested?
What did you do to proceed further until you reached the ALSA impasse?
That's it for starters.
"Any sufficiently advanced information is indistinguishable from noise." [Newman, Lachmann, Moore]
Re: Oolite in a Docker container
OK, I'm running Docker on a Mac (Mojave 10.14.6).
I have XQuartz installed as Xserver (see https://sourabhbajaj.com/blog/2017/02/0 ... ocker-mac/)
I have pushed the image I created to Dockerhub if anyone cares to reproduce: https://hub.docker.com/repository/docke ... 157/oolite
Dockerfile:
I have added the packages to the install list on line 2 as I have hit errors running oolite, and googled for the package name(s).
End of the build:
Running the container (currently it starts bash shell in container, intention will be for oolite to start automatically when it's finished):
So now I am in the container shell, and running xclock as a test (I see the clock GUI on the Mac display).
Ubuntu release info:
So this is ubuntu running in a container (not a VM). It's *minimalist*, and typically would be used for running a server side application.
Running Oolite:
So what I have done so far is find the package associated with the error and added the package to line 2 in the Dockerfile.
As I say, this is a bare bones Ubuntu container. If you can give me the full list of dependencies that Oolite needs to run, I can add these to the Dockerfile and try getting it running.
I have XQuartz installed as Xserver (see https://sourabhbajaj.com/blog/2017/02/0 ... ocker-mac/)
I have pushed the image I created to Dockerhub if anyone cares to reproduce: https://hub.docker.com/repository/docke ... 157/oolite
Dockerfile:
Code: Select all
FROM ubuntu
RUN apt-get update && apt-get install -y apt-utils libglu1-mesa libxml2 libasound2 x11-apps
WORKDIR oolite
COPY oolite-1.90.linux-x86_64.run .
RUN ./oolite-1.90.linux-x86_64.run
End of the build:
Code: Select all
Step 5/5 : RUN ./oolite-1.90.linux-x86_64.run
---> Running in 966fdc17432a
Verifying archive integrity... All good.
Uncompressing Oolite 1.90 .....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Installing Oolite in "/opt/Oolite"...
Copying oolite executable and resources... Done.
Extracting documentation... Done.
Extracting dependencies... Done.
Generating startup and wrapper scripts... Done.
Updating desktop menu...
Warning 127: xdg-utils not properly installed. Oolite desktop menu cannot be installed.
Cleaning up temporary folders... Warning 2: Some temporary files and/or folders could not be deleted.
Finished!
To start Oolite from a shell, run "oolite".
To uninstall Oolite, run "/opt/Oolite/uninstall".
Removing intermediate container 966fdc17432a
---> 731969491a5b
Successfully built 731969491a5b
Successfully tagged crush157/oolite:latest
Code: Select all
$ xhost +$(host_ip_v4) [14:20:12]
192.168.68.111 being added to access control list
$ docker run --rm -it --env DISPLAY=$(host_ip_v4):0 crush157/oolite
root@528a0215d294:/oolite# xclock
Ubuntu release info:
Code: Select all
root@528a0215d294:/oolite# cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.1 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.1 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
Running Oolite:
Code: Select all
root@528a0215d294:/oolite# oolite
This is the first time you've run the game. Here is the README file -
more docs can be found at Oolite/doc/
Press q to exit this document and launch the game
Oolite Binary Release
=====================
Here are some things that you need to know, which will get you out of possible
mishaps.
Keyboard shortcut F12 toggles full screen/windowed mode.
Full screen or windowed mode as well as full screen mode resolutions may be
selected in "Game Options..." from the main game menu (F2 key). The settings
you select will be saved to your user defaults.
Some older (much older) OpenGL cards can't cope with Oolite in higher
resolutions and graphics rendering modes. This may result in textures not
properly rendered, text rendered as blocks, visual artifacts to be displayed
or low perfomance and frame rate. You may try various settings in the
"Game Options..." menu, to check if any of these issues are addressed.
ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
ALSA lib conf.c:4732:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4732:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
ALSA lib conf.c:4732:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5220:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM default
AL lib: (WW) alc_initconfig: Failed to initialize backend "pulse"
ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
ALSA lib conf.c:4732:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4732:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
ALSA lib conf.c:4732:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5220:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM default
AL lib: (EE) alsa_open_playback: Could not open playback device 'default': No such file or directory
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
X Error of failed request: GLXBadContext
Major opcode of failed request: 149 (GLX)
Minor opcode of failed request: 6 (X_GLXIsDirect)
Serial number of failed request: 32
Current serial number in output stream: 31
Erk. It looks like Oolite died with an error. When making an error
report, please copy + paste the log above into the report.
(Press Ctrl-C to continue)
As I say, this is a bare bones Ubuntu container. If you can give me the full list of dependencies that Oolite needs to run, I can add these to the Dockerfile and try getting it running.
-
- ---- E L I T E ----
- Posts: 675
- Joined: Sat Aug 09, 2014 4:16 pm
Re: Oolite in a Docker container
From what it looks like, you're actually failing on libGL initialization:
This is very likely due to the rendering connection between your container and the local X server.
You can try to play with LIBGL_ALWAYS_INDIRECT=1 environment variable, or even LIBGL_ALWAYS_SOFTWARE=1, in your container, before starting oolite.
You can test the above two variables with faster results using glxgears (which should run at a better rate than what Oolite would, as glxgears doesn't use shaders).
Code: Select all
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
X Error of failed request: GLXBadContext
Major opcode of failed request: 149 (GLX)
Minor opcode of failed request: 6 (X_GLXIsDirect)
Serial number of failed request: 32
Current serial number in output stream: 31
You can try to play with LIBGL_ALWAYS_INDIRECT=1 environment variable, or even LIBGL_ALWAYS_SOFTWARE=1, in your container, before starting oolite.
You can test the above two variables with faster results using glxgears (which should run at a better rate than what Oolite would, as glxgears doesn't use shaders).
Re: Oolite in a Docker container
Thanks Commander_X,
That didn't work...but...glxgears in a container *is* something that (according to Google at least) others have got working.
So I have a few blogposts to work through.
That didn't work...but...glxgears in a container *is* something that (according to Google at least) others have got working.
So I have a few blogposts to work through.
-
- ---- E L I T E ----
- Posts: 675
- Joined: Sat Aug 09, 2014 4:16 pm
Re: Oolite in a Docker container
I'm not too versed into (docker) containers, but from what I gathered they seem to be what I'd call "vandalized" virtual machines (i.e. stripped to a -- very -- bare minimum emulation wise, as compared with, say, qemu, virtualbox, vmware & co). I'm not even sure they are supposed to execute a vanilla Linux kernel, let aside sound card, and/or graphics video card emulation.
On the other hand, even the mentioned virtual machines still lack a lot when comes to providing for advanced graphic capabilities. In the open source world I'm only aware of (and trivially checked) the virgl initiative, which only works for qemu/linux guests.
Considering the ecosystem you're driving your test against, it might be worthwhile to check if the XQuartz X server gets good hook(s) into your MacOS video drivers for OpenGL under X, a.k.a. GLX (maybe glxinfo in an xterm can give you some hints to what level of acceleration is available).
On the other hand, even the mentioned virtual machines still lack a lot when comes to providing for advanced graphic capabilities. In the open source world I'm only aware of (and trivially checked) the virgl initiative, which only works for qemu/linux guests.
Considering the ecosystem you're driving your test against, it might be worthwhile to check if the XQuartz X server gets good hook(s) into your MacOS video drivers for OpenGL under X, a.k.a. GLX (maybe glxinfo in an xterm can give you some hints to what level of acceleration is available).
- hiran
- Theorethicist
- Posts: 2403
- Joined: Fri Mar 26, 2021 1:39 pm
- Location: a parallel world I created for myself. Some call it a singularity...
Re: Oolite in a Docker container
Actually Docker is meant to execute server processes in the background. For that reason the Ubuntu container this attempt is based on is a Ubuntu-server, and I did not see that all the graphical UI (X/Wayland) and stuff got installed. It matches the error perceived.Commander_X wrote: ↑Thu Nov 19, 2020 12:59 amI'm not too versed into (docker) containers, but from what I gathered they seem to be what I'd call "vandalized" virtual machines (i.e. stripped to a -- very -- bare minimum emulation wise, as compared with, say, qemu, virtualbox, vmware & co). I'm not even sure they are supposed to execute a vanilla Linux kernel, let aside sound card, and/or graphics video card emulation.
On the other hand, even the mentioned virtual machines still lack a lot when comes to providing for advanced graphic capabilities. In the open source world I'm only aware of (and trivially checked) the virgl initiative, which only works for qemu/linux guests.
Considering the ecosystem you're driving your test against, it might be worthwhile to check if the XQuartz X server gets good hook(s) into your MacOS video drivers for OpenGL under X, a.k.a. GLX (maybe glxinfo in an xterm can give you some hints to what level of acceleration is available).
Rather than going for a Docker container investigate creating an AppImage. Which brings me back to the missing CI/CD pipeline...
Sunshine - Moonlight - Good Times - Oolite