Often times, you want to do some work on unstable, but run stable on your main system. There are other times where you want a test system that's somewhat isolated from your primary desktop.

Chroots are one way of doing this. With a chroot, the chroot guest system shares the kernel, but has a completely different root filesystem. However, the isolation isn't perfect: since the share the same kernel, the chroot can affect things outside if it tries. Thus, it isn't as completly secure as virtualization, but under most non-pathological non-malicious uses, it is a pretty easy and efficient way to test things.

This page explains how to set up and configure a chroots on debian, and the basics of using them for development.

Setup

Install debootstrap on the host system. Run it to install the base system.

sudo debootstrap sid ./chroot-sid
  # sid                == suite to install
  # ./chroot-sid       == destination directory

Now, ./chroot-sid contains a complete Debian system.

You can test it by running the chroot command:

sudo chroot chroot-sid/ /bin/bash

This will run bash inside of the chroot as root. Note that it doesn't share files, for example, at this stage /home is empty and /usr is tiny.

Now, we need to get this set up so that we can easily use the chroot.

Filesystems

The host and guest system are running the same kernel, so they can communicate. We want to use this to make our life easier. Our guest system will share the same /home as the host system. This means t hat you can access the same files inside the chroot as outside - this makes our life easy.

We use the tool schroot to automate this.

schroot

Schroot is an automatic chroot command, that takes care of some extra set-up for us: It automatically bind-mounts the /home and /tmp filesystems, makes your user exist within the chroot, allows you to run root commands inside the chroot.

First off, install the schroot package. Then, edit the config file /etc/schroot/schroot.conf and set it up to know about this chroot. Add this at the very bottom (adjusting the location=, users=, root-users= to the proper values.

[sid]
description=Sid for development
aliases=default
type=directory
location=/home/richard/chroot-sid
users=richard
root-users=richard
run-setup-scripts=true
run-exec-scripts=true

Now, run schroot -c sid. You see

srichard@ramanujan:~$ schroot -c sid
I: [sid-c0a1acda-3204-457b-a84e-57d41804e52e chroot] Running login shell: ‘/bin/bash’
richard@ramanujan:sid:~$ 

Note that your bash prompt changes: it now says :sid in there - this is the name from schroot config file. This way you can tell which of your open shells are in the chroot, and which are not.

If you ls /home now, you'll note that inside the same chroot has the same /home as outside. This means you can access all of your files just as easily within the chroot as outside. Schroot took care of this bind-mounting automatically for us.

You appear in the same relative directory inside the chroot as you did outside: so if you were in ~/dev before, you end up in ~/dev afterwards.

Command summary:

What next?

You should log in to the chroot as root schroot -u root, and run aptitude and install any development packages you need. Then, do all of your development work inside of the chroot, using the unstable build tools.

You should aptitude update and aptitude upgrade inside the chroot every so often.

/etc/apt/sources.list is set to the mirror you used to initially install, and can be different from the mirror outside the chroot. Of course, you can change this to whatever mirror/suite/components you like. Don't forget to change the apt mirror inside if you change the one outside!

Don't forget to occasionally aptitude update/upgrade, especially if this chroot is for unstable development work!

If you eventually have lots of unneeded dependencies in the chroot, or it gets corrupted by broken packages, never fear. Since it's a captive system, you can simply remove all of it, and recreate it. Your files are safely in your primary home directory, so they aren't deleted. BUT WAIT - make sure that there are no bind-mounts remaining inside the chroot, or anything which might cause things to removed recursively outside of the chroot! Basically, check the output from mount and make sure nothing funny is there...