Live manual

Live Systems

<< previous toc next >>

Live Systems Manual


About this manual

1. About this manual

1.1 For the impatient
1.2 Terms
1.3 Authors
1.4 Contributing to this document
1.4.1 Applying changes
1.4.2 Translation

About the Live Systems Project

2. About the Live Systems Project

2.1 Motivation
2.1.1 What is wrong with current live systems
2.1.2 Why create our own live system?
2.2 Philosophy
2.2.1 Only unchanged packages from Debian "main"
2.2.2 No package configuration of the live system
2.3 Contact



3. Installation

3.1 Requirements
3.2 Installing live-build
3.2.1 From the Debian repository
3.2.2 From source
3.2.3 From 'snapshots'
3.3 Installing live-boot and live-config
3.3.1 From the Debian repository
3.3.2 From source
3.3.3 From 'snapshots'

The basics

4. The basics

4.1 What is a live system?
4.2 Downloading prebuilt images
4.3 Using the web live image builder
4.3.1 Web builder usage and caveats
4.4 First steps: building an ISO hybrid image
4.5 Using an ISO hybrid live image
4.5.1 Burning an ISO image to a physical medium
4.5.2 Copying an ISO hybrid image to a USB stick
4.5.3 Using the space left on a USB stick
4.5.4 Booting the live medium
4.6 Using a virtual machine for testing
4.6.1 Testing an ISO image with QEMU
4.6.2 Testing an ISO image with VirtualBox
4.7 Building and using an HDD image
4.8 Building a netboot image
4.8.1 DHCP server
4.8.2 TFTP server
4.8.3 NFS server
4.8.4 Netboot testing HowTo
4.8.5 Qemu
4.9 Webbooting
4.9.1 Getting the webboot files
4.9.2 Booting webboot images

Overview of tools

5. Overview of tools

5.1 The live-build package
5.1.1 The lb config command
5.1.2 The lb build command
5.1.3 The lb clean command
5.2 The live-boot package
5.3 The live-config package

Managing a configuration

6. Managing a configuration

6.1 Dealing with configuration changes
6.1.1 Why use auto scripts? What do they do?
6.1.2 Use example auto scripts
6.2 Clone a configuration published via Git

Customizing contents

7. Customization overview

7.1 Build time vs. boot time configuration
7.2 Stages of the build
7.3 Supplement lb config with files
7.4 Customization tasks

Customizing package installation

8. Customizing package installation

8.1 Package sources
8.1.1 Distribution, archive areas and mode
8.1.2 Distribution mirrors
8.1.3 Distribution mirrors used at build time
8.1.4 Distribution mirrors used at run time
8.1.5 Additional repositories
8.2 Choosing packages to install
8.2.1 Package lists
8.2.2 Using metapackages
8.2.3 Local package lists
8.2.4 Local binary package lists
8.2.5 Generated package lists
8.2.6 Using conditionals inside package lists
8.2.7 Removing packages at install time
8.2.8 Desktop and language tasks
8.2.9 Kernel flavour and version
8.2.10 Custom kernels
8.3 Installing modified or third-party packages
8.3.1 Using packages.chroot to install custom packages
8.3.2 Using an APT repository to install custom packages
8.3.3 Custom packages and APT
8.4 Configuring APT at build time
8.4.1 Choosing apt or aptitude
8.4.2 Using a proxy with APT
8.4.3 Tweaking APT to save space
8.4.4 Passing options to apt or aptitude
8.4.5 APT pinning

Customizing contents

9. Customizing contents

9.1 Includes
9.1.1 Live/chroot local includes
9.1.2 Binary local includes
9.2 Hooks
9.2.1 Chroot local hooks
9.2.2 Binary local hooks
9.2.3 Boot-time hooks
9.3 Preseeding Debconf questions

Customizing run time behaviours

10. Customizing run time behaviours

10.1 Customizing the live user
10.2 Customizing locale and language
10.3 Persistence
10.3.1 The persistence.conf file
10.3.2 Using more than one persistence store
10.3.3 Using persistence with encryption

Customizing the binary image

11. Customizing the binary image

11.1 Bootloaders
11.2 ISO metadata

Customizing Debian Installer

12. Customizing Debian Installer

12.1 Types of Debian Installer
12.2 Customizing Debian Installer by preseeding
12.3 Customizing Debian Installer content


Contributing to the project

13. Contributing to the project

13.1 Translation of man pages

Reporting bugs

14. Reporting bugs

14.1 Known issues
14.2 Rebuild from scratch
14.3 Use up-to-date packages
14.4 Collect information
14.5 Isolate the failing case if possible
14.6 Use the correct package to report the bug against
14.6.1 At build time while bootstrapping
14.6.2 At build time while installing packages
14.6.3 At boot time
14.6.4 At run time
14.7 Do the research
14.8 Where to report bugs

Coding Style

15. Coding Style

15.1 Compatibility
15.2 Indenting
15.3 Wrapping
15.4 Variables
15.5 Miscellaneous


16. Procedures

16.1 Major Releases
16.2 Point Releases
16.2.1 Last Point Release of a Debian Release
16.2.2 Point release announcement template



17. Examples

17.1 Using the examples
17.2 Tutorial 1: A default image
17.3 Tutorial 2: A web browser utility
17.4 Tutorial 3: A personalized image
17.4.1 First revision
17.4.2 Second revision
17.5 A VNC Kiosk Client
17.6 A base image for a 128MB USB key
17.7 A localized GNOME desktop and installer


Style guide

18. Style guide

18.1 Guidelines for authors
18.1.1 Linguistic features
18.1.2 Procedures
18.2 Guidelines for translators
18.2.1 Translation hints


SiSU Metadata, document information

Live Systems Manual


17. Examples

This chapter covers example builds for specific use cases with live systems. If you are new to building your own live system images, we recommend you first look at the three tutorials in sequence, as each one teaches new techniques that will help you use and understand the remaining examples.

17.1 Using the examples

To use these examples you need a system to build them on that meets the requirements listed in Requirements and has live-build installed as described in Installing live-build.

Note that, for the sake of brevity, in these examples we do not specify a local mirror to use for the build. You can speed up downloads considerably if you use a local mirror. You may specify the options when you use lb config, as described in Distribution mirrors used at build time, or for more convenience, set the default for your build system in /etc/live/build.conf. Simply create this file and in it, set the corresponding LB_MIRROR_* variables to your preferred mirror. All other mirrors used in the build will be defaulted from these values. For example:


17.2 Tutorial 1: A default image

Use case: Create a simple first image, learning the basics of live-build.

In this tutorial, we will build a default ISO hybrid live system image containing only base packages (no Xorg) and some live system support packages, as a first exercise in using live-build.

You can't get much simpler than this:

$ mkdir tutorial1 ; cd tutorial1 ; lb config

Examine the contents of the config/ directory if you wish. You will see stored here a skeletal configuration, ready to customize or, in this case, use immediately to build a default image.

Now, as superuser, build the image, saving a log as you build with tee.

# lb build 2>&1 | tee build.log

Assuming all goes well, after a while, the current directory will contain live-image-i386.hybrid.iso. This ISO hybrid image can be booted directly in a virtual machine as described in Testing an ISO image with Qemu and Testing an ISO image with VirtualBox, or else imaged onto optical media or a USB flash device as described in Burning an ISO image to a physical medium and Copying an ISO hybrid image to a USB stick, respectively.

17.3 Tutorial 2: A web browser utility

Use case: Create a web browser utility image, learning how to apply customizations.

In this tutorial, we will create an image suitable for use as a web browser utility, serving as an introduction to customizing live system images.

$ mkdir tutorial2
$ cd tutorial2
$ lb config
$ echo "task-lxde-desktop iceweasel" >> config/package-lists/my.list.chroot

Our choice of LXDE for this example reflects our desire to provide a minimal desktop environment, since the focus of the image is the single use we have in mind, the web browser. We could go even further and provide a default configuration for the web browser in config/includes.chroot/etc/iceweasel/profile/, or additional support packages for viewing various kinds of web content, but we leave this as an exercise for the reader.

Build the image, again as superuser, keeping a log as in Tutorial 1:

# lb build 2>&1 | tee build.log

Again, verify the image is OK and test, as in Tutorial 1.

17.4 Tutorial 3: A personalized image

Use case: Create a project to build a personalized image, containing your favourite software to take with you on a USB stick wherever you go, and evolving in successive revisions as your needs and preferences change.

Since we will be changing our personalized image over a number of revisions, and we want to track those changes, trying things experimentally and possibly reverting them if things don't work out, we will keep our configuration in the popular git version control system. We will also use the best practice of autoconfiguration via auto scripts as described in Managing a configuration.

17.4.1 First revision

$ mkdir -p tutorial3/auto
$ cp /usr/share/doc/live-build/examples/auto/* tutorial3/auto/
$ cd tutorial3

Edit auto/config to read as follows:


lb config noauto \
     --architectures i386 \
     --linux-flavours 686-pae \

Perform lb config to generate the config tree, using the auto/config script you just created:

$ lb config

Now populate your local package list:

$ echo "task-lxde-desktop iceweasel xchat" >> config/package-lists/my.list.chroot

First, --architectures i386 ensures that on our amd64 build system, we build a 32-bit version suitable for use on most machines. Second, we use --linux-flavours 686-pae because we don't anticipate using this image on much older systems. Third, we have chosen the lxde task metapackage to give us a minimal desktop. And finally, we have added two initial favourite packages: iceweasel and xchat.

Now, build the image:

# lb build

Note that unlike in the first two tutorials, we no longer have to type 2>&1 | tee build.log as that is now included in auto/build.

Once you've tested the image (as in Tutorial 1) and are satisfied it works, it's time to initialize our git repository, adding only the auto scripts we just created, and then make the first commit:

$ git init
$ cp /usr/share/doc/live-build/examples/gitignore .gitignore
$ git add .
$ git commit -m "Initial import."

17.4.2 Second revision

In this revision, we're going to clean up from the first build, add the vlc package to our configuration, rebuild, test and commit.

The lb clean command will clean up all generated files from the previous build except for the cache, which saves having to re-download packages. This ensures that the subsequent lb build will re-run all stages to regenerate the files from our new configuration.

# lb clean

Now append the vlc package to our local package list in config/package-lists/my.list.chroot:

$ echo vlc >> config/package-lists/my.list.chroot

Build again:

# lb build

Test, and when you're satisfied, commit the next revision:

$ git commit -a -m "Adding vlc media player."

Of course, more complicated changes to the configuration are possible, perhaps adding files in subdirectories of config/. When you commit new revisions, just take care not to hand edit or commit the top-level files in config containing LB_* variables, as these are build products, too, and are always cleaned up by lb clean and re-created with lb config via their respective auto scripts.

We've come to the end of our tutorial series. While many more kinds of customization are possible, even just using the few features explored in these simple examples, an almost infinite variety of different images can be created. The remaining examples in this section cover several other use cases drawn from the collected experiences of users of live systems.

17.5 A VNC Kiosk Client

Use case: Create an image with live-build to boot directly to a VNC server.

Make a build directory and create an skeletal configuration inside it, disabling recommends to make a minimal system. And then create two initial package lists: the first one generated with a script provided by live-build named Packages (see Generated package lists), and the second one including xorg, gdm3, metacity and xvnc4viewer.

$ mkdir vnc-kiosk-client
$ cd vnc-kiosk-client
$ lb config -a i386 -k 686-pae --apt-recommends false
$ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot
$ echo "xorg gdm3 metacity xvnc4viewer" > config/package-lists/my.list.chroot

As explained in Tweaking APT to save space you may need to re-add some recommended packages to make your image work properly.

An easy way to list recommends is using apt-cache. For example:

$ apt-cache depends live-config live-boot

In this example we found out that we had to re-include several packages recommended by live-config and live-boot: user-setup to make autologin work and sudo as an essential program to shutdown the system. Besides, it could be handy to add live-tools to be able to copy the image to RAM and eject to eventually eject the live medium. So:

$ echo "live-tools user-setup sudo eject" > config/package-lists/recommends.list.chroot

After that, create the directory /etc/skel in config/includes.chroot and put a custom .xsession in it for the default user that will launch metacity and start xvncviewer, connecting to port 5901 on a server at

$ mkdir -p config/includes.chroot/etc/skel
$ cat > config/includes.chroot/etc/skel/.xsession << EOF

/usr/bin/metacity &


Build the image:

# lb build


17.6 A base image for a 128MB USB key

Use case: Create a default image with some components removed in order to fit on a 128MB USB key with a little space left over to use as you see fit.

When optimizing an image to fit a certain media size, you need to understand the tradeoffs you are making between size and functionality. In this example, we trim only so much as to make room for additional material within a 128MB media size, but without doing anything to destroy the integrity of the packages contained within, such as the purging of locale data via the localepurge package, or other such "intrusive" optimizations. Of particular note, we use --debootstrap-options to create a minimal system from scratch.

$ lb config --apt-indices false --apt-recommends false --debootstrap-options "--variant=minbase" --firmware-chroot false --memtest none

To make the image work properly, we must re-add, at least, two recommended packages which are left out by the --apt-recommends false option. See Tweaking APT to save space

$ echo "user-setup sudo" > config/package-lists/recommends.list.chroot

Now, build the image in the usual way:

# lb build 2>&1 | tee build.log

On the author's system at the time of writing this, the above configuration produced a 110MB image. This compares favourably with the 192MB image produced by the default configuration in Tutorial 1.

Leaving off APT's indices with --apt-indices false saves a fair amount of space, the tradeoff being that you need to do an apt-get update before using apt in the live system. Dropping recommended packages with --apt-recommends false saves some additional space, at the expense of omitting some packages you might otherwise expect to be there. --debootstrap-options "--variant=minbase" bootstraps a minimal system from the start. Not automatically including firmware packages with --firmware-chroot false saves some space too. And finally, --memtest none prevents the installation of a memory tester.

Note: A minimal system can also be achieved using hooks, like for example the stripped.hook.chroot hook found in /usr/share/doc/live-build/examples/hooks. It may shave off additional small amounts of space and produce an image of 91MB. However, it does so by removal of documentation and other files from packages installed on the system. This violates the integrity of those packages and that, as the comment header warns, may have unforeseen consequences. That is why using a minimal debootstrap is the recommended way of achieving this goal.

17.7 A localized GNOME desktop and installer

Use case: Create a GNOME desktop image, localized for Switzerland and including an installer.

We want to make an iso-hybrid image for i386 architecture using our preferred desktop, in this case GNOME, containing all of the same packages that would be installed by the standard Debian installer for GNOME.

Our initial problem is the discovery of the names of the appropriate language tasks. Currently, live-build cannot help with this. While we might get lucky and find this by trial-and-error, there is a tool, grep-dctrl, which can be used to dig it out of the task descriptions in tasksel-data, so to prepare, make sure you have both of those things:

# apt-get install dctrl-tools tasksel-data

Now we can search for the appropriate tasks, first with:

$ grep-dctrl -FTest-lang de /usr/share/tasksel/descs/debian-tasks.desc -sTask
Task: german

By this command, we discover the task is called, plainly enough, german. Now to find the related tasks:

$ grep-dctrl -FEnhances german /usr/share/tasksel/descs/debian-tasks.desc -sTask
Task: german-desktop
Task: german-kde-desktop

At boot time we will generate the de_CH.UTF-8 locale and select the ch keyboard layout. Now let's put the pieces together. Recalling from Using metapackages that task metapackages are prefixed task-, we just specify these language boot parameters, then add standard priority packages and all our discovered task metapackages to our package list as follows:

$ mkdir live-gnome-ch
$ cd live-gnome-ch
$ lb config \
     -a i386 \
     --bootappend-live "boot=live components locales=de_CH.UTF-8 keyboard-layouts=ch" \
     --debian-installer live
$ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot
$ echo task-gnome-desktop task-german task-german-desktop >> config/package-lists/desktop.list.chroot
$ echo debian-installer-launcher >> config/package-lists/installer.list.chroot

Note that we have included the debian-installer-launcher package to launch the installer from the live desktop. The 586 kernel flavour, which is currently necessary for the launcher to work properly, will be included by default.

<< previous toc next >>