Safer Way to Run Bleeding Edge Software on Debian and Ubuntu

You may have noticed that some software in your distribution is not the latest available. Most people are not even aware of this because, often, it’s not an issue. It’s only when you need some very recent features when it becomes an issue. Let’s say your favorite video editor had some code changes that improve rendering time by 20%. That may be something you want.

Long story short, most distributions that are considered “stable” or “long term support” will have (at least partially) older software in their repositories. But “rolling distros” have much newer software included, as they constantly pull in updates from upstream developers. Debian Unstable (codenamed Sid) is such a distribution. With some command-line magic, you can run Debain Sid inside your current installation of Debian Stable or Ubuntu.

Why Do this When I Can Just Add PPAs or Backports?

Personal Package Archives are very popular among users that want to add newer software to Ubuntu. But PPAs, backports (on Debian), and other similar methods interfere with your main installation. That means that they may upgrade bits and pieces of your main system. This increases the risk of something going wrong, incompatibilities between new and old software, new bugs introduced in the operating system and so on.

In contrast, the method in this tutorial isolates software in a separate space and doesn’t interfere with your main installation in any way. It’s somewhat similar to a container (minus the strong security features). Furthermore, Debian Sid includes much more software than you will find in PPAs or backports. However, everything has its limitations, so keep in mind the notes from the Debian Unstable page.

Create a Minimal Debian Sid Installation with debootstrap

Open a terminal emulator and install “debootstrap:”

Change to your home directory;

Start to bootstrap a new Debian Sid installation in the “debian-sid” directory:

The process will take a while, so wait a few minutes.


Prepare Your Debian Sid Installation

First, install a new package.:

Now, use a newly installed utility to “step into” your Debian Sid distro:

If you ever get stuck in this container, you can press Ctrl + ] three times in a row to forcefully exit. Use it only as an emergency method.

Add a new user. In this example the user is simply called “user,” but you can replace it with your desired username, although what this is called has no importance.


Choose a password for this user. No text will be displayed when you type. After you press Enter, type the same password again when prompted. The next details, such as “Full Name,” are not required, so you can simply press Enter at these prompts. Finally, type “y” when asked if the information is correct, and press Enter.

Install sudo:

Add the user to the sudo group:

Set the hostname for your container. This will help you on the terminal, making it clearer when you are logged in to the container and when you are on your main system. It will help avoid mistakes.

Exit from your Debian Sid container:

Virtually Boot Debian Sid Container with systemd-nspawn

A simple chroot command could have been used to step into this container, but systemd-nspawn has stronger isolation methods. This better prevents the container from “leaking out” into your main system accidentally. Furthermore, the utility includes a virtual boot switch. What this does is simulate a real boot of your Debian Sid installation. This launches some background processes that some applications may require to function properly (for example, dbus).

“Boot” your Debian Sid installation:


Log in with the username and password chosen earlier.

Install and Run Desired Software

Say you want to install the GIMP image editor:

Shutdown your container so you can reboot with all the new stuff it installed (dependencies like dbus):

Whenever you are done working with the container, this is the command you should use to quit.

GIMP is a graphical application, so it needs a graphical server. For technical reasons, this is not running in your container but is running on your main system. Run this on your main operating system (not in the container):

You may get an answer such as :0.0.

Boot the container again:

After you log in, tell the container where it can find the display.

Replace :0.0 if you had a different answer.

This only works with the Xorg graphical server. If you’re using Wayland, you may need to do the above with the WAYLAND_DISPLAY variable instead of DISPLAY. If that doesn’t work, temporarily use Xorg through your login manager’s options.

Now you can run gimp:


Don’t mind the warnings in the terminal. You get those on any system when you run a graphical app from the terminal. It’s normal output. You just don’t usually see it since you normally start applications from a graphical launcher.


It may be hard to get to this point, but once you’re done, it’s easy to install new software. Just boot the container, apt install, export display, run app. Once you have everything you need, you just have to upgrade occasionally. Do that with apt update && apt upgrade. Sometimes you may also have to use apt update && apt full-upgrade after the previous command.

Alexandru Andrei

Fell in love with computers when he was four years old. 27 years later, the passion is still burning, fueling constant learning. Spends most of his time in terminal windows and SSH sessions, managing Linux desktops and servers.


  1. Nice. Didn’t know, one can run graphical apps inside a bootstraped environment. Thanks!

  2. Can’t say I understand all of this but it feels impressive and clever. I keep thinking about any performance issues (not highlighted in the article) and the key differences between this versus containers, flatpaks and snapfiles as a way of isolating/testing new programs on a live system.

    One thing the article didn’t cover was completely removing these changes (both the new install and the framework). I’m a big fan of statically linked binaries for this reason. If the app offends in any way, sooo easy to remove all remnants.

    1. There is no performance impact, so any program runs at full speed. This is like installing Windows 10 inside Windows 7, in a way.

      What is presented here is simply a directory, that contains a minimal operating system environment. So, to remove it, you just “sudo rm -rf debian-sid” to remove the directory. systemd-container is meant to contain all actions within this environment. So, while you’re “inside” this directory, there’s no way to accidentally write stuff to your host operating system, remove files, format partitions, etc. While you’re there, the programs you run just believe they’re running under that guest operating system. And any action you perform will only be able to write within this container. So it’s a capsule that won’t mess anything on your main/host operating system.

      But this does not offer security measures because it is meant to run software you trust. What this means is that very clever malware, can find ways to escape this container and leak into your main system. But it should be written with this purpose in mind. So, first of all, you must first get infected somehow. Then, you should have such bad luck that it was written specifically to escape your chroot/systemd-container. Normal software won’t “accidentally” escape the container, even if it malfunctions somehow, you won’t wake up with your main partition gone. It will just mess up the container. So this is a great way to also test programs, compile, develop, etc.

      Think of this as a snap for an entire Debian operating system. The exception to a virtual machine is that this operating system doesn’t really have to boot up, it will just use your already booted kernel. So, it’s actually just a bunch of files, newer libraries, newer programs, in a directory.

      Snaps and flatpaks are meant as a way to contain a single application, that you may sometimes not even trust completely. That’s why they have better security features. There is also a small performance impact, although absolutely negligible.

      1. @Alexandru: Thanks for an explanation on this! debootstrap sounds extremely useful. I thought it was newish tech but some further searches indicate it’s been around for a good long while (ie, time tested, which is great).

        I’ve been toying around with the idea of setting up an environment that was command-line driven only. This would have required downloading and installing lots of programs to test – some as GUI replacements, many similar programs (tons of editors to look at), etc. Already have a good number listed but not installed… concerned about issues I might create on my current system.

        I think debootstrap solves a lot of problems I might have encountered and would let me create an isolated testbed environment – something like DOSBox but for Linux. Loved the “sudo rm -rf debian-sid” advice as a quick way of starting over. That was the clincher! Excited to give this a try.

  3. Hi,

    If I want to ‘backup’ the contained system, can I just exit from it, and copy the debian-sid directory?

    To restore, then just delete the existing debian-sid and rename the backup?



    1. That should work. But you have to copy as root, so prefix the copy command with sudo. There are some files in there owned by the root user and only root can preserve that owner. Furthermore, you should also add parameters to preserve file permissions. So a command like “sudo cp -arv debian-sid debian-sid2” should do the job.

Comments are closed.