Distrobox tricks: this escalated rather quickly

In the previous post, Distrobox had a perfectly reasonable job: give an application the distribution it expected, then let it appear in the desktop launcher.

That should have been the end of it. Application installed, problem solved, go outside.

Unfortunately, the documentation has a section about running an entire desktop from a container, and another about putting libvirt in one. Somewhere between those two pages, installing Signal stopped looking like a particularly ambitious use of the afternoon.

Here are six things you can do with Distrobox, starting with the useful ones and gradually moving towards the sort of setup you find yourself explaining with a diagram.

These assume Distrobox and a working container manager are already installed. I’ll use rootless Podman for the ordinary boxes. The libvirt example has different requirements, which we’ll get to. Shell commands run on the host unless the block says otherwise.

1. Give each project its own little tool cupboard

One project needs a particular compiler. Another needs development headers from a different distribution. A third has a README last updated when Python 2 was still a reasonable thing to mention in public.

Eventually your host becomes an archaeological record of everything you’ve ever tried to build.

With Distrobox Assemble, you can keep the setup in the project. Save this as distrobox.ini:

[project-tools]
image=docker.io/library/ubuntu:24.04
additional_packages="build-essential git pkg-config python3 python3-venv"
root=false
replace=false

Then create and enter it:

distrobox assemble create --file ./distrobox.ini
distrobox enter project-tools

For a project under your shared home, the source files are already accessible inside. Install the project’s dependencies there and do the build with the container’s tools. Use a different container name for each project environment.

The manifest records the image and packages you want. replace=false keeps repeated creation from replacing an existing box. A release tag still follows updates, though, and package repositories change: this is a setup recipe, not an exact dependency lockfile.

There is also a useful bridge in the other direction. From inside the box:

distrobox-host-exec xdg-open https://distrobox.it/

That asks the host to open the URL with its usual handler. You can also run distrobox-host-exec podman ps to inspect the host’s containers. The host-exec documentation explains how commands cross back out. Your development shell can live in Ubuntu while your browser remains wherever you left it.

2. Borrow a distribution, then give it back

Sometimes you only want to check a package, try a command, or see whether a script behaves differently on another distribution. Keeping a permanent container for each five-minute question is how you end up naming things test-final-really-final.

Use an ephemeral box:

distrobox ephemeral --image docker.io/library/ubuntu:24.04 -- bash

You get a shell in a temporary container. Install the tools you need, investigate the thing, and type exit. Distrobox removes the container when the command ends. Downloaded images can remain cached, so this doesn’t promise to reclaim every byte involved.

It is particularly handy for answering small compatibility questions: does this command exist in the distribution’s repositories? What version do they ship? Does this shell script quietly assume that /bin/sh is Bash?

One catch deserves to travel with the command: the usual shared-home behaviour still applies. Files you edit there survive the container. Distrobox’s security notes explain its deliberate host integration. Temporary containers are useful for disposable package installations; your home directory hasn’t agreed to be disposable too.

3. Invite ARM to an x86 laptop

Suppose you want to exercise an ARM userspace without finding the Raspberry Pi, its power supply, and whichever drawer currently contains the working SD card.

Distrobox supports choosing another platform, with QEMU user emulation doing the translation. First set up the host’s QEMU user emulators and binfmt registrations using your distro’s instructions. Package names vary; the official Distrobox notes describe the prerequisites.

Once that machinery works, an x86-64 host can create an ARM64 box:

distrobox create \
  --name arm-lab \
  --image docker.io/library/ubuntu:24.04 \
  --platform linux/arm64

distrobox enter arm-lab -- uname -m

The command should report aarch64. You can then install ARM packages and investigate architecture-specific build or dependency problems.

This has an emulation cost, and it doesn’t reproduce a whole ARM machine. QEMU’s user-mode documentation explains that system calls ultimately go to the host kernel. Boot behaviour, device drivers and hardware testing still need an appropriate machine or full system emulation.

Useful for finding out whether your binary starts. Less useful for finding out whether you wired the GPIO pins backwards.

4. Give GPU software its own dependency collection

GPU applications have a talent for arriving with an entourage. Libraries, build tools, Python packages, occasionally an instruction to replace something you were quite attached to.

Distrobox can provide a separate userspace for those tools while exposing the host GPU. Its GPU notes cover Intel and AMD through the container’s Mesa/DRI packages, plus NVIDIA integration.

On a host with a working NVIDIA driver, one route starts like this:

distrobox create \
  --name gpu-lab \
  --image docker.io/library/ubuntu:24.04 \
  --nvidia

distrobox enter gpu-lab

The --nvidia option attempts to integrate the host driver into the box. It doesn’t install your application or a complete CUDA development environment; those still need setting up inside.

The documented alternative uses NVIDIA Container Toolkit, configured on the host, with a suitable image and container-manager options. In either case, the GPU driver remains a host responsibility.

The appeal is having an environment you can dedicate to one workload without adding its entire dependency collection to the base system. The graphics card, regrettably, still costs real money.

5. Take another desktop out for a walk

Here is where the scope starts looking suspicious.

The official desktop experiment covers running GNOME, KDE Plasma and Hyprland from a Distrobox container. The base distribution can stay put while the desktop session comes from another userspace.

For GNOME and Plasma, the documented approach installs the desktop in the container and adds a session entry to the host’s display manager. Selecting that entry starts the desktop through distrobox-enter. The guide also covers the extra device and session plumbing needed for Hyprland.

So the answer to “which distro are you running?” becomes a small administrative meeting.

This is explicitly marked experimental. The examples are release-specific and need adapting to your current desktop, display manager and graphics setup. Keep a working host session available while experimenting.

It is an interesting way to explore a desktop from another distribution while retaining your existing base. It also makes the separation between the kernel, the distribution’s userspace and the desktop surprisingly tangible. Those things usually arrive in one installer, which makes it easy to forget that they can have separate addresses.

6. Put the virtual machine department in a container

This one has a practical audience: people using immutable desktops who want a local virtualization stack without installing all its packages into the base OS.

Distrobox has an official libvirt walkthrough that puts QEMU, libvirt and virt-manager in a container. Its example uses openSUSE’s Distrobox image, a rootful container, an init system, and additional namespace separation. That differs substantially from the ordinary rootless project boxes above.

The resulting arrangement looks like this:

Host Linux + KVM
    └── Distrobox container
            ├── libvirt + QEMU + virt-manager
            └── Virtual machines, each with its own guest kernel

The container holds the virtualization tools and services. The VMs still use the host’s KVM capabilities, and each VM boots its own kernel. Distrobox itself continues to share the host kernel.

The guide exports virt-manager to the host’s application menu and also describes connecting over SSH. Follow the complete setup there: getting the services, permissions and networking right is most of the work.

A rootful box has host-level consequences, so this deserves more attention than a temporary shell. Still, a container running the service that runs your virtual machines is a pleasing amount of machinery to fit behind one menu entry.

Remember which machine you’re talking to

All of these get easier to manage if you give the boxes descriptive names and make the container name visible in your shell prompt. project-tools and arm-lab tell you something useful. ubuntu3 tells you that at some point there were two others.

Keep the distinction between package isolation and access to the host in mind, especially when moving from the ordinary rootless examples to the desktop and libvirt experiments. A separate userspace gives software somewhere else to keep its dependencies; the integration is still what makes Distrobox comfortable to use.

For everyday work, I’d start with a project manifest and an ephemeral shell. Those earn their keep quickly. The desktop and virtualization experiments can wait until you have a free afternoon and have already accepted that going outside may not happen.