Trying to run MH in a Linux chroot container.

If your topic doesn't fit anywhere else, put it here.

Moderator: joepal

Trying to run MH in a Linux chroot container.

Postby bobg » Sun Feb 21, 2021 7:33 am

Hi all,
First, please forgive me if this post seems to be outside the bounds of the MakeHuman software. I have MH working perfectly on my Linux Mint 20.1 system. I am trying to get it to work within a chroot container on this same system. The reason I think you may be able to help is because the problem seems to do with python3 not finding the ctype: GL within the container despite the fact that all libraries, drivers, busses, sockets, apps, etc, are simply remounted from the main system into the container system. The only thing left out from the main OS is the user home directories. The container has a new assigned user. Blender and some opengl test programs such as glxgears are running fine within the container. They output to the main system's desktop display with no problem.

The error message occurs right after succesfully loading numpy;
Code: Select all
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/OpenGL/platform/glx.py", line 14, in GL
    return ctypesloader.loadLibrary(
  File "/usr/lib/python3/dist-packages/OpenGL/platform/ctypesloader.py", line 45, in loadLibrary
    return dllType( name, mode )
  File "/usr/lib/python3.8/ctypes/__init__.py", line 373, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: ('GL: cannot open shared object file: No such file or directory', 'GL', None)


I've used NVidia's 390 drivers on my geforce 1080 for a long time and it has worked perfectly when some of their later drivers were flaky. I reinstalled it tonight since opengl support comes from NVidia's installed software. No change.

I know almost nothing about python is the reason I'm asking if anyone can clarify what python is looking for. It seems to want an opengl.so library which does not exist at all in Linux Mint 20.1 (including the repositories). Yet, MH runs perfectly from the main system without this library.

TIA for any clarification of the python ctype:GL.

Best regards,
Bob G.
bobg
 
Posts: 6
Joined: Fri Aug 09, 2019 7:58 pm

Re: Trying to run MH in a Linux chroot container.

Postby joepal » Sun Feb 21, 2021 9:23 am

It is surprising that python does not find the shared object if the entire system is available through the chroot.

The two deb files probably related to the shared object are these:

Code: Select all
09:58:19 [joepal@ligur ~]$ dpkg -l | grep -i python | grep -i gl
ii  python3-opengl                                3.1.0+dfsg-2build1                          all          Python bindings to OpenGL (Python 3)
ii  python3-pyqt5.qtopengl                        5.14.1+dfsg-3build1                         amd64        Python 3 bindings for Qt5's OpenGL module


You can list the contents of these packages with dpkg -L:

Code: Select all
10:19:37 [joepal@ligur ~]$ dpkg -L python3-pyqt5.qtopengl
/.
/usr
/usr/lib
/usr/lib/python3
/usr/lib/python3/dist-packages
/usr/lib/python3/dist-packages/PyQt5
/usr/lib/python3/dist-packages/PyQt5/QtOpenGL.cpython-38-x86_64-linux-gnu.so
/usr/lib/python3/dist-packages/PyQt5/QtOpenGL.pyi
/usr/lib/python3/dist-packages/PyQt5/_QOpenGLFunctions_2_0.cpython-38-x86_64-linux-gnu.so
/usr/lib/python3/dist-packages/PyQt5/_QOpenGLFunctions_2_1.cpython-38-x86_64-linux-gnu.so
/usr/lib/python3/dist-packages/PyQt5/_QOpenGLFunctions_4_1_Core.cpython-38-x86_64-linux-gnu.so
/usr/share
/usr/share/doc
/usr/share/doc/python3-pyqt5.qtopengl
/usr/share/doc/python3-pyqt5.qtopengl/copyright
/usr/share/doc/python3-pyqt5.qtopengl/NEWS.gz
/usr/share/doc/python3-pyqt5.qtopengl/changelog.Debian.gz


You could do the corresponding on your system and make sure that all relevant .so object really are available in the chroot.

Another explanation might be if the chroot fails at identifying the system correctly so that python looks in the wrong place for .so objects. For example, if the chroot causes the system to think it is 32-bit while the so files are 64 bit, then python might look for the wrong file.
Joel Palmius (LinkedIn)
MakeHuman Infrastructure Manager
http://www.palmius.com/joel
joepal
 
Posts: 4465
Joined: Wed Jun 04, 2008 11:20 am

Re: Trying to run MH in a Linux chroot container.

Postby bobg » Mon Feb 22, 2021 12:08 pm

Thank you for such a prompt and informative response. I ran that test as root from within the container and got an exact match with the output in your example. The libraries are definitely there. Still, I've tried MH as root and got the same error. I entered the 'arch' command as container root and got back 'x86_64'. It's strange that some intensive graphics like Blender are working perfectly. I keep thinking that narrows thing down to qt since Blender uses python extensively.

I wish I knew more about python. I would like to perhaps set some debug messages in the appropriate python module to see what python sees and where it's looking. Sadly I'm not sure I'm up to learning another programming language at age 78.

This started out looking like a fun little project to fully populate a container and then finding what, if anything could be left off and still have full functionality. I was trying to establish a baseline definition of a minimal chroot container with full graphics. I've search the internet for matches to the error message (found some but no help.) I double checked links and spellings as best I can for a couple days but I am stumped. I would be grateful for any further thoughts you have.

Best regards,
Bob G.
bobg
 
Posts: 6
Joined: Fri Aug 09, 2019 7:58 pm

Re: Trying to run MH in a Linux chroot container.

Postby joepal » Tue Feb 23, 2021 6:38 am

Qt also does some funky stuff based on environment variables. Maybe compare the output of "env" from within and outside a chroot?

Other potential avenues are making sure /proc, /sys and /dev are properly mounted. It is not enough to bind-mount just the root. You probably know this already, but the minimal setup for a functional chroot that can access some hardware is roughly:

Code: Select all
mkdir /mnt/my_new_root
mount -o bind / /mnt/my_new_root
mount -o bind /dev /mnt/my_new_root/dev
mount -o bind /proc /mnt/my_new_root/proc
mount -o bind /sys /mnt/my_new_root/sys
mount -o bind /run /mnt/my_new_root/run


However, even with doing this on my machine, there are things missing for Qt. It doesn't really seem to have contact with X, which is maybe not all that surprising:

Code: Select all
qt.qpa.xcb: could not connect to display
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

Avbruten (SIGABRT) (minnesutskrift skapad)


Maybe something like this is a possible way forward? https://www.elstel.org/xchroot/ (I haven't tried this myself)
Joel Palmius (LinkedIn)
MakeHuman Infrastructure Manager
http://www.palmius.com/joel
joepal
 
Posts: 4465
Joined: Wed Jun 04, 2008 11:20 am

Re: Trying to run MH in a Linux chroot container.

Postby bobg » Fri Mar 05, 2021 2:28 pm

Just an update.
Sorry it has taken so long to get back to you but as I pulled into a Walmart parking lot my car accelerator went full throttle. I managed to control the situation and got it parked with no harm done but it has been my main focus for a few days. Bad linkage bracket let the cable go free.
I haven't got MH going yet but I am homing in on the problem. Taking the error message literally, I tried reading the standard '/etc/X11/xorg.conf' file and to my amazement there wasn't one. I've never seen this before. I was able to generate a config file using 'nvidia-xconfig' but it still does not specify the opengl package. It's a generic xorg.conf file. More research pending.
Also, to be clear, here are the individual mount bindings for my chroot container;
/bin
/dev
/etc
/proc
/run
/sys
/tmp
/var
/usr

Despite setbacks I'm totally enjoying having an active project with a bit of a challenge. It's been a long time.

Best regards, Bob G.
bobg
 
Posts: 6
Joined: Fri Aug 09, 2019 7:58 pm

Re: Trying to run MH in a Linux chroot container.

Postby loki1950 » Fri Mar 05, 2021 5:00 pm

Xorg.conf has been not used for about six years now :shock: was related to the development of Wayland if I remember correctly.

Enjoy the Choice :)
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo Ideapad 320-15ABR Win 10/Mint 19
User avatar
loki1950
 
Posts: 1219
Joined: Thu Dec 18, 2014 6:27 pm
Location: Ottawa,Ontario

Re: Trying to run MH in a Linux chroot container.

Postby bobg » Sat Mar 06, 2021 1:33 am

The last piece of the puzzle fell into place. I was bind mounting /tmp as read only. Mounting it r/w allowed MH to come up in my container. Thanks for all the assistance which helped tremendously.

If anyone else is interested in doing this, here is the basics. I use a skeletal linux system within a 20GB file created using the 'dd' command. The file is encrypted when not in use. the file is mounted through a loop device and formatted with mkfs. As mounted, it should only contain empty folders which are populated by using 'mount --bind' to mount the true system directories to the empty directories in your container. Leave the 'home' directory empty and as root within the container you can create a new user login which will stay within your container only. You enter the container using the command 'sudo chroot /mnt/my-mounted-container' which puts you as root within the container. On the host side use the bash command 'xhost local:' to allow the container user to access the host desktop display. There are lots of controls such as 'cgroups' and using optional 'readonly' privileges during mount that can provide restrictions within the container. I made a shell script that brings everything up ready to enter the container.

Best regards,
Bob G.

EDIT: Forgot to mention, I also installed a lot of qt5 support type stuff which called in even more qt5 stuff. Somewhere in there the ctype:GL problem got fixed although it still needed the /tmp fix.
bobg
 
Posts: 6
Joined: Fri Aug 09, 2019 7:58 pm


Return to General discussions about makehuman

Who is online

Users browsing this forum: No registered users and 1 guest