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.
Install debootstrap on the host system. Run it to install the base system.
sudo debootstrap sid ./chroot-sid http://mirror.cc.columbia.edu/pub/linux/debian/debian/ # sid == suite to install # ./chroot-sid == destination directory # http://... == mirror 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.
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 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.
schroot -- get a shell in the chroot
schroot -c sid -- log into the chroot named sid from the config file (if you have multiple chroots)
schroot -u root -- get a root shell in the chroot (requires password unless you are in schroot.conf is told so)
schroot somecommand -- runs that command in the chroot
schroot somecommand --option argument -- runs that command in the chroot
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...