GUI apps in LXD (Archlinux Host)

I managed to replicate the issue; indeed with lxc console mycontainer something is different and the X application does not start.

Here is the output

$ lxc console mycontainer
To detach from the console, press: <ctrl>+a q

Ubuntu 18.04.1 LTS mycontainer console

mycontainer login: ubuntu
Password: *************

ubuntu@mycontainer:~$ xclock
Error: Can't open display: 
ubuntu@mycontainer:~$ 

Until I figure out what’s going on, you can follow the following guide,

and get the shell with

lxc ubuntu mycontainer

Well, still can’t open display :0

The container is ubuntu from repo, package x11-apps, mesa-utils installed, minimal profile you provide assigned and alias is set up. I made every step carrefully, restarted everything and still no protocol specified.

Is it possible that my arch box is the problem?
Otherwise if I do ls -l /tmp/.X11-unix/X0 command in the container I get user ubuntu and group nogroup. I’m wondering if it can cause issues?

lxc console gets you attached to a getty process spawned by PID 1.

PID 1 (systemd) ignores the environment variables we set for it and doesn’t propagate them down to its children. The result is that lxc exec BLAH bash will have all the environment.* keys respected while lxc console BLAH will not.

I tried to find some help on Arch forums, I did not find an answer about the socket not working but someone suggested me to try x11 forwarding over ssh instead. I’ll explore that…
Thanks @simos for your help and your tutorials.

ArchLinux has these extra steps to run unprivileged containers,
https://wiki.archlinux.org/index.php/Linux_Containers#Enable_support_to_run_unprivileged_containers_(optional)

I did follow these steps.
In the meantime X11 forwarding over ssh is a good alternative.

The fact is I’m wondering if it has to do with the installation of the distro. To be precise, I use to make base install without desktop env or extra packages, then I install the needed one.
Arch / debian base install (wihout desktop env pre-installed) I get the X0 error.
However, with a fully desktop env (xfce) installation on debian, it is working.

I tried installing Arch and the whole installation process is so involved. It just feels a shame to start with a trial installation but then not stick with it as your only distro until the end of times.
Also, these AUR packages do not have some official tool to build them. yaourt, which is discussed on the various forums, is now obsolete?

Have you seen the Arch image from osboxes? I’ll give it a go and see how it works.

So, I managed to make this work.

In summary, on Arch you are either required to run xhost +local: on the host, or create a suitable .Xauthority in the container. On top of the other instructions.

By running on the host xhost +local:, you allow local users to use your desktop’s X server.
You can later remove this right with xhost -local:.

The $XAUTHORITY file contains a cookie and the hostname of the computer that is allowed to make the connection. Which means that if you copy verbatim your host’s $XAUTHORITY to the container, it will not work (unless the container is also named the same as the host). Or, if you edit $XAUTHORITY to accept any hostname.

2 Likes

Ha excellent! I was gonna tell you the same thing thanks to an arch user.
But he said there are security implications using xhost -local: and I don’t fully understand why.

Also, this command does not persist after a reboot.

Yes indeed, that’s one of the reasons I find arch interesting. This distro force you to really understand how things are working.

You can use makepkg command to build them and use the regular package manager to remove them like pacman -Rs somepackage.
I did use Yaourt but it was a long time ago and as makepkg is straighforward and the need of package from AUR is occasional, I don’t see the point of using it anymore.