build


It is very handy to have a chroot jail for testing code snippets, packages, releases. This is on your (Debian) dev box, where you may have multiple installed versions of related libs. Before promoting your new code to Test or Staging, it can be a time saver to first test it in a pristine environment that can’t be affected by files outside the ‘jail’. For example, I have several versions of Perl installed on my dev box and several versions of EV around the place. When testing something against EV I want to be sure I haven’t omitted any dependencies and to be sure I’m testing against exactly the version I’m expecting. You should treat the jail as throw-away; keep in mind that you can (and should) delete and build a fresh one whenever the mood takes you. There are many online notes about creating one, but it is still hard to find any that tell you how to get it ironed out easily, eg to avoid confusing sessions that are inside/outside the jail.

Install packages

mkdir -p /opt/jail/mojo
debootstrap wheezy /opt/jail/mojo

(and then wait a few mins while it downloads and installs). Then install locales.

chroot /opt/jail/mojo
dpkg-reconfigure debconf  # setting priority to 'medium'
vi /etc/apt/sources
apt-get update
apt-get install locales less vim rsync
locale-gen en_GB.UTF-8

That last line is to generate any locales that the previous line reported as missing; if you don’t see any such warnings (on the commandline) then none are needed.

Make it clear you are in jail

vi /etc/debian_chroot

giving it the jail name as content, in this example ‘Mojo’.

vi /etc/skel/.bashrc
vi /etc/bash.bashrc

removing all instances of “@\h“, eg by doing “:%s/@\\h//gc” with repeated presses of y

adduser --ingroup users --disabled-password --gecos 'test user,,,' tester
su - tester

and check that your commandline prompt shows the jail name and not the (parent) hostname. If you’re using an xterm you should also see its title change to something similar when you ‘sub user’ to ‘tester’. The remaining step for this section is to do likewise for ‘root’. The simplest way to do that is to copy the xterm lines from /etc/skel/.bashrc so that /root/.bashrc now has

case "$TERM" in
xterm*|rxvt*)
  PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u: \w\a\]$PS1"
  ;;
*)
  ;;
esac

Now open a new xterm and test both user envs

chroot /opt/jail/mojo
su - tester

checking that in both cases the xterm title and the commandline prompt are clearly different from those of the (parent) host.

(The rest of these notes are standard fodder for getting processes to work nicely.)

Mount Parts of Host System

Before installing more packages or running processes, you’ll need to integrate /proc
In /etc/fstab of the host box, I have a section for each jail

/dev/pts /opt/jail/mojo/dev/pts none bind 0 4
proc     /opt/jail/mojo/proc    proc defaults 0 4
sysfs    /opt/jail/mojo/sys     sysfs defaults 0 4

and then mount them manually (again as ‘root’ in the host box)

mount /opt/jail/mojo/dev/pts
mount /opt/jail/mojo/proc
mount /opt/jail/mojo/sys

Fake your mtab

You’ll find that df fails because the chroot has no /etc/mtab. Some people are advocating cat /proc/mounts >/etc/mtab but that is wrong, the partitions inside the chroot are in general completely different to those outside. In my case I give the missing file just one line

rootfs / rootfs rw 0 0

which does all that I want.

Set your timezone

You can manipulate /etc/timezone and /etc/localtime yourself, but the easiest way is to

dpkg-reconfigure tzdata

Sometimes you want tight control of the partition that Windows is installed into. For instance, with Windows 7 you may want to avoid the 100 MB system-reserved partition by presenting the installation with an existing partition. I don’t care much about the 100 MB but I do care about losing one of my four primary partitions when building a dual/triple boot system. It turns out the answer is very easy, using diskpart:
Hack to remove 100 MB system partition
Using diskpart

Some useful notes on which bits of C:\WINDOWS can be deleted: http://support.microsoft.com/kb/956324

msiexec /a C:\tmp\some.msi /qb TARGETDIR=C:\tmp\xx

The folder C:\tmp\xx will be created if it doesn’t exist.
Keep paths absolute; relatives (eg ..\some.msi) don’t work.

Follow

Get every new post delivered to your Inbox.