I've run X.org in container with a host without X.org succesfully in LXD

I need to run graphics applications in an LXC container, but I’m not allowed to install X.org on the host side. Therefore, I had to attempt running the X.org server on the container side, and fortunately, I succeeded. To commemorate this hard-earned victory, I have decided to document the method I used so that others can benefit from it.

Make the graphics work

Just simply mount the gpu and /dev/fb0 and /dev/tty* to cantainer. For example:

$ lxc config device add MY_CANTAINER mygpu gpu productid=xxxx vendorid=xxxx
$ lxc config device add MY_CANTAINER fb0 unix-char path=/dev/fb0 source=/deb/fb0
$ lxc config device add MY_CANTAINER tty0 unix-char path=/dev/tty0 source=/dev/tty0

And it may be better to add the lxd to the user group video and tty:

sudo usermod -aG tty lxd
sudo usermod -aG video lxd

Then restart container and install xorg, and run startx to test if X.org works.

It should work well.

There was an error xf86EnableIO: failed to enable I/O ports 0000-03ff (Operation not permitted), Idk how to fix but it doesn’t matter, Xorg runs well.

Manage input event

According to this web, mount the /dev/uinput and /dev/input/* and run the script mentioned in the web, restart the container.

Problems remain

The way I manage the input events by mounting all files under /dev/input/* is ugly. And I have to reconfigure the container after I pull out mouse or keyboard, or else the container wouldn’t start.

I’ve tried to mount the entire /dev/input directory, but it doesn’t work. Looks like there are some permission problems. But I don’t know how to deal with that till now. ( I’ve tried to mount the entire /dev, and the contain just cannot starts T_T)

ps: sorry for some grammar errors above, I’m trying my best to express my ideas in English and hope I can make you understand :slight_smile:


I’ll close this topic since LXD is a no longer a Linux Containers project, but this is very cool stuff you’ve done here!

To handle hotplug, the unix-hotplug device type may be able to handle that in a more flexible way, the main downside though is that it will only work for devices plugged in after the container is started…

I suspect you could use the /dev/input/by-id or /dev/input/by-path to get a more fixed handled on the input devices you want to pass in, something that will survive across reboot.

1 Like