Installing the needed tools on Debian Wheezy is a matter of:
$ sudo apt-get install virtualbox vagrant rake
Then, please run:
$ git clone git://git.tails.boum.org/tails $ cd tails $ git checkout devel $ export TAILS_BUILD_OPTIONS="noproxy" $ rake build $ unset TAILS_BUILD_OPTIONS
The first time, this can take a little while to download the base virtual
machine from Tails mirror (around 300 MB). It will then boot the machine,
set it up and start the build process. When done, several
should appear in the current directory.
After you are done working on Tails, do not forget to shut the virtual machine down:
$ rake vm:halt
One may also want to customize their image before building.
To know all available Rake tasks, please run
If you have a local HTTP proxy, the build system will use it as long as
you properly set the
http_proxy environment variable. The easiest way to
do so is to run:
$ export http_proxy=http://proxy.lan:3142
This needs to be done before any other operations.
Options regarding the build process can be set using the
TAILS_BUILD_OPTIONS environment variable. Muliple options must be
separated by whitespaces.
The following options are available:
Tails builds way faster when everything is done in memory. If your computer runs Linux and happens to have more than 6.5 GB of free memory before you start the virtual machine, it will automatically switch to 'build in RAM' mode.
To force a specific behaviour please set:
- ram: start the virtual machine with 6.5GB of memory, build Tails
tmpfs. Build fails if the system is not in a proper state to do so.
- noram: start the virtual machine with 1GB of memory if not already done, build Tails using the virtual machine hard disk.
Building Tails requires downloading a little bit more than 1 GB of Debian packages. To preserve bandwidth and developer sanity, using a HTTP proxy is nearly a must. Tails virtual machine contains a fully configured local HTTP proxy that will be used if no other local proxy is defined.
The following flags can be used to force a specific behaviour:
- extproxy: use the proxy configured through the
http_proxyenvironment variable. Fail if it is not set.
- vmproxy: use the local proxy configured in the virtual machine even if a local HTTP proxy is set.
- noproxy: do not use any HTTP proxy.
A Tails build starts with
debootstrap:ing a minimal Debian system
which then is modified into a full Tails system. This is a rather time
consuming step that usually does not have to be done: the packages used
in it rarely get updated and hence the result is exactly the same most
of the time.
The following flags can be used to force a specific behaviour:
- cache: re-use a cached bootstrap stage (if available), and saves the bootstrap stage to disk on successful build. This will also reduce the amount of memory required for in-memory builds by around 150 MiB (see the ram option above). Warning: this option may create subtle differences between builds from the exact same Tails source which are hard to track to track and understand. Use this option only if you know what you are doing, and if you are not building an actual release.
- nocache: do the bootstrap stage from scratch (default).
One of the most expensive operations when building Tails is the creation
of the final SquashFS. It also depends on the compression algorithm used.
When working on the
testing branch, the image will be made
using the slow but efficient default. Any other setup will switch to the
Forcing a specific behaviour can be done using:
- gzipcomp: always use gzip to create the SquashFS.
- defaultcomp: always use the default compression algorithm.
Some operations are preserved accross builds. Currently they are:
- The wiki (for documentation).
- The bootstrap stage cache (see the cache option above).
In case you want to delete all these, the following option is available:
- cleanall: force a clean up before starting the build.
The number of virtual CPUs that are allocated in the virtual machine can be set through:
- cpus=n: allocate n CPUs to the virtual machine.
Obviously you should not allocate more virtual CPUs than the number of cores available to the host system. When using Linux, the number of CPUs allocated will default to be the same as the host system.
The build system can only work on files that have been commited to the Git repository. By default, it will refuse to start a build in presence of uncommited changes. This behaviour can be controlled by:
- ignorechanges: allow to make a build that will ignore changes in the Git repository.
The fastest build you could pretend to get can be done by setting:
export TAILS_BUILD_OPTIONS="ram cache extproxy gzipcomp"
This will force the build to happen in RAM and allow skipping the boostrap stage if one is cached, and will use use an HTTP proxy external to the virtual machine, and SquashFS compression will be done using gzip.
The following Debian packages need to be installed:
syslinux>= 4.01, so that the built ISO images are converted to hybrid ones: they can be either a CD-ROM or a hard disk (USB disk, etc.).
whois(for /usr/bin/mkpasswd) packages.
ikiwiki3.20120725 or newer.
apt-get install libyaml-perl libyaml-libyaml-perl po4a perlmagick libyaml-syck-perlso that the wiki builds smoothly.
Add these lines to
Every build command must be run as
root, at the root of a clone of the
In short, a build could be done using:
# lb clean --all && lb config && lb build
If you need to set custom build settings that are specific to your local environment, such as a custom Debian mirror or APT proxy, you probably want to configure live-build a bit.
The most common customizations are documented on this wiki:
- to avoid compressing the SquashFS using XZ (efficient, but very
export MKSQUASHFS_OPTIONS='-comp gzip'in your build environment;
- using a custom Debian mirror to build Tails images;
- using squid-deb-proxy to build Tails images.
More documentation about this can be found in the Debian Live Manual.
Initialize the Live system's configuration with
lb config in a
clean build tree. Most
lb config options are supported, have a
look to the
lb_config(1) manpage for details.
You can then use the standard live-build commands as root to build
the image (
lb build) and to cleanup the build directory (
More documentation about the build process can be found in the Debian Live Manual.