- the live systems tool suite
] [ --breakpoints
] [ --force
live-build is a set of scripts to build live system images. The idea behind
live-build is a tool suite that uses a configuration directory to completely
automate and customize all aspects of building a Live image.
is a name of a live-build command (see below).
More documentation about how to use live-build is available in the individual
manpages for each helper and in the manual at <
Shared live-build options¶
The following command line options are supported by all live-build programs.
- -h, --help
- display help and exit.
- -u, --usage
- show usage and exit.
- -v, --version
- output version information and exit.
Common live-build options¶
The following command line options are supported by most live-build programs.
See the man page of each program for a complete explanation of what each
- run with breakpoints.
- use custom configuration file.
- show debug information.
- force helper execution, even if stage file exists.
- be quiet.
- be verbose.
We divide live-build into high level ("porcelain") commands and low
level ("plumbing") commands.
Here is the complete list of all available live-build commands. See their man
pages for additional documentation.
HIGH-LEVEL COMMANDS (PORCELAIN)¶
We separate the porcelain commands into the main commands and some ancillary
Main porcelain commands¶
- create configuration for live-build
- create the first stage by bootstrapping a basic debian
- create the second stage by customizing the chroot
- create the third stage by generating a binary image
- create the optional fourth stage by generating a source
- clean up system build directories
- generic live-build wrapper
- alias for all stages
- helper for using a local live-build
- ensure that a system is built as root
LOW-LEVEL COMMANDS (PLUMBING)¶
The actual work of live-build is implemented in the low-level commands, called
plumbing. They are not supposed to be used by end users, they should stick
with porcelains as they ensure that all the different plumbing commands are
executed in the right order. However, if you intend to reuse live-build
commands in your own scripts, then the plumbings might be of interest for you.
Note that the interface (set of options and the semantics) to these low-level
commands are meant to be a lot more stable than Porcelain level commands. The
interface to Porcelain commands on the other hand are subject to change in
order to improve the end user experience.
- cache bootstrap stage
- bootstrap a Debian system with debootstrap(8)
- manage /etc/apt/apt.conf
- cache chroot stage
- manage /etc/debian_chroot
- mount /dev/pts
- manage /sbin/dpkg
- execute hacks in chroot
- manage /bin/hostname
- manage /etc/hosts
- install queued packages into chroot
- make build interactive
- manage /etc/kernel-img.conf
- execute local hooks in chroot
- copy local files into chroot
- queue install of packages into chroot
- apply local patches against chroot
- use debconf local preseeding file
- queue install of package lists into chroot
- mount /proc
- manage /etc/resolv.conf
- mount /selinux
- manage /etc/apt/sources.list
- mount /sys
- manage /usr/sbin/policy-rc.d
- install task lists into chroot
- copy chroot into chroot
- install debian-installer into binary
- install disk information into binary
- installs grub into binary
- installs grub2 into binary
- copy files into binary
- build iso binary image
- install linux-image into binary
- execute local hooks in binary
- copy files into binary
- install local package lists into binary
- create manifest
- create binary checksums (md5, sha1, and/or sha256)
- installs a memtest into binary
- build netboot binary image
- build rootfs image
- installs syslinux into binary
- build harddisk binary image
- build binary hdd image
- installs win32-loader into binary
- download sources
- copy debian-live config into source
- install disk information into source
- build iso source image
- create source checksums (md5, sha1, and/or sha256)
- build source net image
- build source tarball
- build source hdd image
Many live-build commands make use of files in the config/
control what they do. Besides the common config/common
, which is used
by all live-build commands, some additional files can be used to configure the
behavior of specific live-build commands. These files are typically named
config/stage or config/stage_helper (where "stage" of course, is
replaced with the name of the stage that they belong to, and
"helper" with the name of the helper).
For example, lb_bootstrap_debootstrap uses files named config/bootstrap and
config/bootstrap_debootstrap to read the options it will use. See the man
pages of individual commands for details about the names and formats of the
files they use. Generally, these files contain variables with values assigned,
one variable per line. Some programs in live-build use pairs of values or
slightly more complicated variable assignments.
Note that live-build will respect environment variables which are present in the
context of the shell it is running. If variables can be read from config
files, then they override environment variables, and if command line options
are used, they override values from config files. If no value for a given
variable can be found and thus is unset, live-build will automatically set it
to the default value.
In some rare cases, you may want to have different versions of these files for
different architectures or distributions. If files named config/stage.arch or
config/stage_helper.arch, and config/stage.dist or config/stage_helper.dist
exist, where "arch" is the same as the output of "dpkg
--print-architecture" and "dist" is the same as the codename of
the target distribution, then they will be used in preference to other, more
All config files are shell scripts which are sourced by a live-build program.
That means they have to follow the normal shell syntax. You can also put
comments in these files; lines beginning with "#" are ignored.
This program is a part of live-build.
More information about live-build and the Live Systems project can be found on
the homepage at < http://live-systems.org/
> and in the manual at
Bugs can be reported by submitting a bugreport for the live-build package in the
Bug Tracking System at < http://bugs.debian.org/
> or by writing a
mail to the Live Systems mailing list at <
live-build was written by Daniel Baumann <