Before containers, before Virtualbox, there was chroot [1]. Chroot does precisely what its name implies: It changes the apparent root directory, isolating it in what is known as a chroot or jail. By itself, a chroot jail falls short of a complete guest operating system, but in a Debian-based system, you can come close to one, thanks to debootstrap [2]. The result is a semi-independent installation of Debian or derivative running on the same machine as your main installation.

The chroot command first appeared in Version 7 Unix in 1979, and in BSD in 1982, where it was used to test the installation and build system. How chroot operates has remained almost entirely unchanged over the years. However, because you cannot detect the system's true root or its directory tree from within a chroot jail, you are severely limited in what you can do unless you install a separate operating system in the jail – a task that can be daunting if done manually. What debootstrap does is remove the drudgery, making the installation of a CLI operating system a matter of a single command. Similarly, schroot simplifies the daily management of the jail.

Once the chroot is configured, it becomes ideal for sandboxing [3] – testing a program where it can do minimal harm because it is isolated from the host operating system. In fact, the first use of chroot was to test an installation and build system. Today, debootstrap  – usually with the addition of schroot, the chroot manager – remains an important tool for package maintainers who build and test packages for multiple hardware platforms.

Regular users can also use chroot as a base from which to troubleshoot or even upgrade the main system or to run 32-bit programs on a 64-bit system. Despite competition from containers and virtual machines, debootstrap remains an option for all these purposes and more.

If nothing else, because a jail uses the same memory resources as its host, it is far more economical than a virtual machine. You might think of debootstrap as an ancestral version of Docker, the application for creating containers (which is also build upon chroot) [4].

Installing a Chroot Jail

Before creating a chroot jail, use the command apt-get install to add the debootstrap and schroot packages to your system. Then, run uname -a to find the architecture of your machine, such as i386 or amd34 (if the architecture is listed as i686, use i386 in the command). Use mkdir to create a mountpoint for the jail, such as /srv/sid, and the name of the repository that will run in it, such as sid for the Debian repository.

Debootstrap includes scripts for installing all but the most recent versions of Debian and Ubuntu at /usr/share/debootstrap/scripts (Figure 1). You should also be able to run other Debian-derived distributions, such as Linux Mint, either by modifying the scripts provided or by copying the script from the other distribution's version of debootstrap.

Figure 1: Debootstrap supports all but the latest Debian and Ubuntu releases by default.

The first step is to prepare schroot. To work with schroot, each chroot requires a profile, either in a separate file in /etc/schroot/chroot.d/JAIL-NAME.conf or as a stanza in /etc/schroot/schroot.conf. In both cases, the profile requires the fields listed in Table 1.

Next, install the jail using debootstrap (Figure 2). Debootstrap uses the following command structure:

Figure 2: Installing a chroot jail using debootstrap.

debootstrap --arch ARCHITECTURE CHROOT-PATH REPOSITORY-NAME \
  REPOSITORY-URI

For example, assuming you wanted to install a version of Sid on a 32-bit system, the command would be:

debootstrap --arch i386 sid /srv/sid http://http.debian.net/debian

The architecture is particularly important if you are installing a 32-bit chroot on a 64-bit system. Be aware, too, that if your chroot is using Debian unstable (Sid), you might run into temporarily broken packages.

Most of the time, however, you should have no problems. You can use the option --include= followed by a comma-separated list to install extra packages, and --verbose shows more information during installation. You should not need other options, but if you do, see the debootstrap man page for details.

At this point, you have a minimal installation of about 100MB with a command-line interface in the chroot. You can confirm that the jail is properly configured by running schroot -l, which gives a list of valid jails (Figure 3). To enter a jail on the list, use the command structure schroot -c JAIL-NAME -u root – for instance:

Figure 3: The command schroot -l lists all the jails that are ready to use.

schroot -c sid -u root

The chroot is designed primarily for use from the command line because chroot jails are an advanced feature for which many desktop users have little use. Additionally, because of the jail's status as a guest operating system, you cannot run a desktop on top of that of the host operating system, which means installing a desktop environment inside the jail is pointless. However, you can run a desktop application from within the chroot by exporting the host's DISPLAY environment with the command structure:

DISPLAY=:0.0 ./APPLICATION

The application opens in its own window on your host's desktop. Depending on your X server and the details of your configuration, the display of the application may take up to 20 seconds to open or have a lower resolution than the host.

Isolating the Jail Further

When you switch to the chroot, note that the prompt still shows the host installation's name, which indicates that the host and the jail share the same IP address (Figure 4). In fact, many basic resources are copied from the host system each time you enter the chroot to keep the host and jail synchronized. However, although this sharing saves space, you do not always want it. You may want the jail to be even more isolated or, for resources and configurations created in the chroot, to last more than a single session. To prevent this sharing, you can open a jail using the --preserve-environment option for the schroot command. However, if you forget to use the option, you can still wipe out the jail's environment.

Figure 4: Debootstrap installs a minimal guest system. The prompt is the same as on the host system, which is an indication of how the host and guest share resources.

A more permanent solution is to keep the jail running and open /etc/schroot/default/nssdatabases on the host system in a text editor. The file contains a list of databases for different aspects of the system: passwords (passwd), shadow (encrypted passwords), groups, services, protocols, networks, and hosts. Comment out each database you do not want copied to the chroot each time it starts by adding # to the start of its line. After you save the file, you can close the jail and restart it without losing information you have added.

Going into More Depth

These are only the basic instructions for creating schroot jails with debootstrap and managing them with schroot. In particular, you might want to study other uses of schroot, such as the --all option to open all chroots at once or --user=USER to run in other than root mode.

If you want to run Fedora or one of its derivatives, you can use febootstrap [5] or supermin [6]. Febootstrap installs chroot jails in much the same way as debootstrap but is not designed to be run as root, and it cannot run 32-bit operating systems on 64-bit ones. Supermin is more versatile – currently supporting both Debian-like and Fedora-like systems, and possibly others in the future – but it is still being rapidly developed.

You might not want to run such programs as a regular substitute for a virtual desktop, although chroots have been used to supplement the shortages of utilities in 64-bit systems for years. All the same, for many purposes, debootstrap and schroot in combination are ensuring that chroot jails remain a useful part of the Linux toolkit, even a quarter century after their invention.