Using LXD to get 32 bits applications/steam to work on an amd64 only systems

There is a plan to drop support for 32-bit packages in Ubuntu, starting from Ubuntu 19.10.
I see lots of misinformation, so let’s try to put all this in order.

If you are affected, read Intel 32bit packages on Ubuntu from 19.10 onwards and specifically read the FAQ.

This change affects Ubuntu 19.10 (non-LTS) and newer versions. Older versions are unaffected. Unaffected versions are Ubuntu 16.04 LTS (desktop support up to 2021, containers up to 2026) and Ubuntu 18.04 LTS (desktop support up to 2023, containers up to 2028).

32-bit libraries are a mess on 64-bit systems. They are an indication that things will start getting bad on your system. I do not install 32-bit libraries on my desktop. If I need an application that comes with 32-bit libraries, I install it in a container.

Here is my tutorial on getting Steam to work in a LXD container. Bonus screenshots of running CS:GO Danger Zone.

Here is my generic guide on running GUI applications in a LXD container. I use an example of running “redet”, a package only available in Ubuntu 12.04! And I am running it in a Ubuntu 12.04 container under Ubuntu 18.04.

Here is my tutorial on running Wine in a LXD container.

I believe that it is possible to get rid of the 32-bit legacy by using container, whether those are Docker or LXD or something else.

LXD is a good candidate, and by creating a GUI LXD manager to create containers, it should make it easy for everyone to confine 32-bit legacy applications inside containers. And not mess our desktops!


Here is an ironic article about Steam not supporting 32-bit Linux distributions.
You heard this right, this happened in 2016. Valve decided to switch to the Chromium browser for the Steam Web Browser, therefore if a user had a 32-bit Linux distribution, they were unable to use the Steam client.

Why? That’s a purely subjective opinion with no rational argument behind it.

But then you still need to support the NVidia drivers. Which means you’ll have to maintain the NVidia drivers for 18.04 forever if you don’t want people to lose their old games at some point in the future. And with that, we’re back to Canonical supporting 32-bit installations.

And there’s another problem with that: Steam is meant as a universal game launcher, but if you want to both run 32-bit games and take advantage of the latest 64-bit libraries in the host system, you’ll need to switch back and forth between two different Steam client installations depending on the game. That’s not a good UX.

If there’s a good solution for seamlessly supporting legacy 32-bit applications and 32-bit Wine via containers, I’m all for it. But I don’t see how such a solution would be less work for Canonical than simply continuing to maintain the most important 32-bit libraries.

1 Like

Since 2016, Steam requires a mixed 32-bit/64-bit Linux system. You cannot run Steam anymore on a pure 32-bit Linux distribution because the Steam Web Browser is a 64-bit application only (because Chromium, etc).
Therefore, you would still get a single container, a mixed 32-bit/64-bit Linux container, to run Steam.

My point was that if we now have to run Steam in a 18.04 container forever, it won’t be able to take advantage of the updates in newer releases of Ubuntu. Unless you also install it on the 64-bit-only host system, but then you’ll have to deal with two different installations on the same PC.

Let’s run Steam in Ubuntu 19.10 (no 32-bit support on the host)!
We show how to do this with an NVidia GPU, which is a bit more complicated than AMD/Intel.
We do not show how to setup audio, for simplicity.

We are going to show the actual steps. The steps can get even shorter by using profiles.
Someone will probably make some nice GUI for this.

  1. Install LXD on Ubuntu 19.10.

    sudo snap install lxd
  2. Setup LXD. Keep the defaults on all questions.

    sudo lxd init
    usermod -G lxd -a myusername
    newgrp lxd
  3. Launch a container.

     lxc launch ubuntu:18.04 steam
  4. Add the GPU to the container (GPU Passthrough)

    lxc config device add steam gt2060 gpu
  5. Share the X11 Unix socket of the host to the container

    lxc config device add steam X0 proxy listen=unix:@/tmp/.X11-unix/X0 connect=unix:@/tmp/.X11-unix/X0 bind=container security.uid=1000 security.gid=1000 
  6. Get a shell into the LXD system container

    lxc exec steam -- sudo --user ubuntu --login
  7. Add the NVidia 430 driver to this Ubuntu 18.04 LTS container, using the PPA.

    sudo add-apt-repository ppa:graphics-drivers/ppa
  8. Install the NVidia library. Also install utilities to test X11, OpenGL and Vulkan.

    sudo apt install -y libnvidia-gl-430
    sudo apt install -y x11-apps mesa-utils vulkan-utils
  9. Set the $DISPLAY

    export DISPLAY=:0
  10. Enjoy by testing X11, OpenGL and Vulkan.


The system is now ready to install Steam, and also Wine!

1 Like

I’ve put this into a blog post,

What will you do when 18.04 becomes EOL and these libraries are no longer available at all? At that point, this solution will no longer work at all.

Also, they will not update the NVIDIA drivers for 18.04 forever. At some point, you will be stuck with an old NVIDIA driver and unable to update to anything newer. When 18.04 becomes EOL, those NVIDIA drivers will most likely go away entirely.

You, and everyone at Canonical, seem to be assuming that we’re mad about not having 32-bit applications anymore. That isn’t the case at all. We already moved on from not being able to install Ubuntu on a 32-bit system (and I personally don’t care since barely anyone uses 32-bit desktops and laptops these days).

But removing 32-bit libraries that are essential for Steam, Wine, etc. is pure madness. Arch, & Fedora don’t offer 32-bit distributions, but they still support multiarch.

The Wine maintainer in Debian even mentioned that Wine64 is useless without Wine32 because most Windows installers use 32-bit (even if the application themselves is 64-bit).

And I mentioned this in another thread:

Best of both worlds, right?

Ubuntu 18.04 desktop gets support until 2023. The container image (relevant here) gets support until 2028. Isn’t that enough?

No. I still play games from 20 years ago. Some of my games will never stop being 32bit. There is no reason to stop me from playing them as long as we are using processors which can run them.

Also, that would mean that, at best, in less than 9 years Steam is no longer usable on Ubuntu. Steam will most likely not stop selling 32bit games as long as we are using processors that support them which means they will continue to require 32bit libraries.

It is disingenuous to pull a you all and we.
There was similar drama when Ubuntu dropped the i386 ISOs and now noone is concerned. Even Steam does not run on a i386 ISO since 2016.
Software gets better and craft is reduced.

That is not even close to the same thing. The need to support 32bit hardware is dying and almost dead (you can get the same computing power of most 32bit machines out of a cheap Raspberry Pi). The need to support 32bit software still exists for many users every day.

I believe that in 2028 you will be able to get a computer that is powerful enough to run multiple VMs and you will not be concerned at all about package compatibility. You would install the old distro ISO of your preference and then your favorite game.

LXD supports container images for several operating systems, including debian, centos, fedora, alpine, opensuse, devuan and more. If any of the other operating systems is fine with 32-bit libraries, you can use those instead.

No, I’ll just install a distribution that still supports 32bit libraries (there are quite a few that show no signs of dropping multilib support). Suggesting LXD in the first place is kind of crazy if you really think about it. Ubuntu is supposed to be one of the most user friendly distros out there… not something that requires users to run many things in a terminal to get their programs working.

Wait, the issue we are discussing is not 32-per se, the issue is Intel 32-bit (i386). The RPi has the architectures armhf and arm64, which are both fine (and not relevant to the discussion).

I am explaining with the command line how these work because it is not some black box. It is simple enough that it is possible to create a GUI manager that creates the prepared containers for you.

If you do not have a requirement for hardware acceleration, it is even simpler to use X2Go, as shown at
With X2Go, you can launch a full operating system (like Mate) in a container.

And your solution is still a temporary band-aid just as any other solution offered for this problem. Sorry, but removing 32bit support entirely is not an acceptable thing to do at this point in time.

When you have to run legacy software, you either go for a virtual machine (full OS virtualisation), or you use a runtime (containers, Docker or LXD). It is a bit too much to expect software compatibility with running libraries from decades ago.

Here is an example. retdec is some Tcl/Tk program from a decade ago. There is a package for retdec in Ubuntu 12.04 (universe repository) but that package has not been updated to work with newer versions of Ubuntu or Debian. It just does not work on newer distributions. You would need to use a VM (takes resources on current computers), or you can use a runtime of Ubuntu 12.04 (container image) and run the application with minimal affect to performance.
That’s what I demonstrate at running retdec on Ubuntu 18.04 inside an Ubuntu 12.04 container, with no performance penatly.