Debian Live 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

2. About the Debian Live 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'

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

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

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

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

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 Desktop and language tasks
8.2.8 Kernel flavour and version
8.2.9 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

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 Live/chroot local hooks
9.2.2 Boot-time hooks
9.2.3 Binary local hooks
9.3 Preseeding Debconf questions

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

11. Customizing the binary image

11.1 Bootloader
11.2 ISO metadata

12. Customizing Debian Installer

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


13. Contributing to the project

13.1 Making changes

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

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. Git repositories

17.1 Handling multiple repositories


18. Examples

18.1 Using the examples
18.2 Tutorial 1: A default image
18.3 Tutorial 2: A web browser utility
18.4 Tutorial 3: A personalized image
18.4.1 First revision
18.4.2 Second revision
18.5 A VNC Kiosk Client
18.6 A base image for a 128MB USB key
18.7 A localized GNOME desktop and installer


18.8 Guidelines for authors
18.8.1 Linguistic features
18.8.2 Procedures
18.9 Guidelines for translators
18.9.1 Translation hints

Debian Live Manual


4. The basics

This chapter contains a brief overview of the build process and instructions for using the three most commonly used image types. The most versatile image type, iso-hybrid, may be used on a virtual machine, optical medium or USB portable storage device. In certain special cases, as explained later, the hdd type may be more suitable. The chapter finishes with instructions for building and using a netboot type image, which is a bit more involved due to the setup required on the server. This is an slightly advanced topic for anyone who is not familiar already with netbooting, but it is included here because once the setup is done, it is a very convenient way to test and deploy images for booting on the local network without the hassle of dealing with image media.

Throughout the chapter, we will often refer to the default filenames produced by live-build. If you are downloading a prebuilt image instead, the actual filenames may vary.

4.1 What is a live system?

A live system usually means an operating system booted on a computer from a removable medium, such as a CD-ROM or USB stick, or from a network, ready to use without any installation on the usual drive(s), with auto-configuration done at run time (see Terms).

With Debian Live, it's a Debian GNU/Linux operating system, built for one of the supported architectures (currently amd64 and i386). It is made from the following parts:

  • Linux kernel image, usually named vmlinuz*
  • Initial RAM disk image (initrd): a RAM disk set up for the Linux boot, containing modules possibly needed to mount the System image and some scripts to do it.
  • System image: The operating system's filesystem image. Usually, a SquashFS compressed filesystem is used to minimize the Debian Live image size. Note that it is read-only. So, during boot the Debian Live system will use a RAM disk and 'union' mechanism to enable writing files within the running system. However, all modifications will be lost upon shutdown unless optional persistence is used (see Persistence).
  • Bootloader: A small piece of code crafted to boot from the chosen medium, possibly presenting a prompt or menu to allow selection of options/configuration. It loads the Linux kernel and its initrd to run with an associated system filesystem. Different solutions can be used, depending on the target medium and format of the filesystem containing the previously mentioned components: isolinux to boot from a CD or DVD in ISO9660 format, syslinux for HDD or USB drive booting from a VFAT partition, extlinux for ext2/3/4 and btrfs partitions, pxelinux for PXE netboot, GRUB for ext2/3/4 partitions, etc.
  • You can use live-build to build the system image from your specifications, set up a Linux kernel, its initrd, and a bootloader to run them, all in one medium-dependant format (ISO9660 image, disk image, etc.).

    4.2 Downloading prebuilt images

    While the focus of this manual is developing and building your own live images, you may simply wish to try one of our prebuilt images, either as an introduction to their use or instead of building your own. These images are built using our live-images git repository and official stable releases are published at ‹›. In addition, older and upcoming releases, and unofficial images containing non-free firmware and drivers are available at ‹›.

    4.3 Using the web live image builder

    As a service to the community, we run a web-based live image builder service at ‹›. This site is maintained on a best effort basis. That is, although we strive to keep it up-to-date and operational at all times, and do issue notices for significant operational outages, we cannot guarantee 100% availability or fast image building, and the service may occasionally have issues that take some time to resolve. If you have problems or questions about the service, please contact us, providing us with the link to your build.

    4.3.1 Web builder usage and caveats

    The web interface currently makes no provision to prevent the use of invalid combinations of options, and in particular, where changing an option would normally (i.e. using live-build directly) change defaults of other options listed in the web form, the web builder does not change these defaults. Most notably, if you change --architectures from the default i386 to amd64, you must change the corresponding option --linux-flavours from the default 486 to amd64. See the lb_config man page for the version of live-build installed on the web builder for more details. The version number of live-build is listed at the bottom of the web builder page.

    The time estimate given by the web builder is a crude estimate only and may not reflect how long your build actually takes. Nor is the estimate updated once it is displayed. Please be patient. Do not refresh the page you land on after submitting the build, as this will resubmit a new build with the same parameters. You should contact us if you don't receive notification of your build only once you are certain you've waited long enough and verified the notification e-mail did not get caught by your own e-mail spam filter.

    The web builder is limited in the kinds of images it can build. This keeps it simple and efficient to use and maintain. If you would like to make customizations that are not provided for by the web interface, the rest of this manual explains how to build your own images using live-build.

    4.4 First steps: building an ISO hybrid image

    Regardless of the image type, you will need to perform the same basic steps to build an image each time. As a first example, create a build directory, change to that directory and then execute the following sequence of live-build commands to create a basic ISO hybrid image containing a default live system without It is suitable for burning to CD or DVD media, and also to copy onto a USB stick.

    The name of the working directory is absolutely up to you, but if you take a look at the examples used throughout live-manual, it is a good idea to use a name that helps you identify the image you are working with in each directory, especially if you are working or experimenting with different image types. In this case you are going to build a default system so let's call it, for example, live-default.

    $ mkdir live-default && cd live-default

    Then, run the lb config command. This will create a "config/" hierarchy in the current directory for use by other commands:

    $ lb config

    No parameters are passed to lb config, so defaults for all of its various options will be used. See The lb config command for more details.

    Now that the "config/" hierarchy exists, build the image with the lb build command:

    # lb build

    This process can take a while, depending on the speed of your computer and your network connection. When it is complete, there should be a binary.hybrid.iso image file, ready to use, in the current directory.

    4.5 Using an ISO hybrid live image

    After either building or downloading an ISO hybrid image, which can be obtained at ‹›, the usual next step is to prepare your medium for booting, either CD-R(W) or DVD-R(W) optical media or a USB stick.

    4.5.1 Burning an ISO image to a physical medium

    Burning an ISO image is easy. Just install xorriso and use it from the command-line to burn the image. For instance:

    # apt-get install xorriso

    $ xorriso -as cdrecord -v dev=/dev/sr0 blank=as_needed binary.hybrid.iso

    4.5.2 Copying an ISO hybrid image to a USB stick

    ISO images prepared with xorriso, can be simply copied to a USB stick with the dd program or an equivalent. Plug in a USB stick with a size large enough for your image file and determine which device it is, which we hereafter refer to as ${USBSTICK}. This is the device file of your key, such as /dev/sdb, not a partition, such as /dev/sdb1! You can find the right device name by looking in dmesg's output after plugging in the stick, or better yet, ls -l /dev/disk/by-id.

    Once you are certain you have the correct device name, use the dd command to copy the image to the stick. This will definitely overwrite any previous contents on your stick!

    $ dd if=binary.hybrid.iso of=${USBSTICK}

    4.5.3 Using the space left on a USB stick

    To use the remaining free space after copying binary.hybrid.iso to a USB stick, use a partitioning tool such as gparted or parted to create a new partition on the stick. The first partition will be used by the Debian Live system.

    # gparted ${USBSTICK}

    After the partition is created, where ${PARTITION} is the name of the partition, such as /dev/sdb2, you have to create a filesystem on it. One possible choice would be ext4.

    # mkfs.ext4 ${PARTITION}

    Note: If you want to use the extra space with Windows, apparently that OS cannot normally access any partitions but the first. Some solutions to this problem have been discussed on our mailing list, but it seems there are no easy answers.

    Remember: Every time you install a new binary.hybrid.iso on the stick, all data on the stick will be lost because the partition table is overwritten by the contents of the image, so back up your extra partition first to restore again after updating the live image.

    4.5.4 Booting the live medium

    The first time you boot your live medium, whether CD, DVD, USB key, or PXE boot, some setup in your computer's BIOS may be needed first. Since BIOSes vary greatly in features and key bindings, we cannot get into the topic in depth here. Some BIOSes provide a key to bring up a menu of boot devices at boot time, which is the easiest way if it is available on your system. Otherwise, you need to enter the BIOS configuration menu and change the boot order to place the boot device for the live system before your normal boot device.

    Once you've booted the medium, you are presented with a boot menu. If you just press enter here, the system will boot using the default entry, Live and default options. For more information about boot options, see the "help" entry in the menu and also the live-boot and live-config man pages found within the live system.

    Assuming you've selected Live and booted a default desktop live image, after the boot messages scroll by, you should be automatically logged into the user account and see a desktop, ready to use. If you have booted a console-only image, such as standard or rescue flavour prebuilt images, you should be automatically logged in on the console to the user account and see a shell prompt, ready to use.

    4.6 Using a virtual machine for testing

    It can be a great time-saver for the development of live images to run them in a virtual machine (VM). This is not without its caveats:

  • Running a VM requires enough RAM for both the guest OS and the host and a CPU with hardware support for virtualization is recommended.
  • There are some inherent limitations to running on a VM, e.g. poor video performance, limited choice of emulated hardware.
  • When developing for specific hardware, there is no substitute for running on the hardware itself.
  • Occasionally there are bugs that relate only to running in a VM. When in doubt, test your image directly on the hardware.
  • Provided you can work within these constraints, survey the available VM software and choose one that is suitable for your needs.

    4.6.1 Testing an ISO image with QEMU

    The most versatile VM in Debian is QEMU. If your processor has hardware support for virtualization, use the qemu-kvm package; the qemu-kvm package description briefly lists the requirements.

    First, install qemu-kvm if your processor supports it. If not, install qemu, in which case the program name is qemu instead of kvm in the following examples. The qemu-utils package is also valuable for creating virtual disk images with qemu-img.

    # apt-get install qemu-kvm qemu-utils

    Booting an ISO image is simple:

    $ kvm -cdrom binary.hybrid.iso

    See the man pages for more details.

    4.6.2 Testing an ISO image with virtualbox

    In order to test the ISO with virtualbox:

    # apt-get install virtualbox virtualbox-qt virtualbox-dkms

    $ virtualbox

    Create a new virtual machine, change the storage settings to use binary.hybrid.iso as the CD/DVD device, and start the machine.

    Note: For live systems containing that you want to test with virtualbox, you may wish to include the VirtualBox driver package, virtualbox-guest-dkms and virtualbox-guest-x11, in your live-build configuration. Otherwise, the resolution is limited to 800x600.

    $ echo "virtualbox-guest-dkms virtualbox-guest-x11" >> config/package-lists/my.list.chroot

    In order to make the dkms package work, also the kernel headers for the kernel flavour used in your image need to be installed. Instead of manually listing the correct linux-headers package in above created package list, the selection of the right package can be done automatically by live-build.

      $ lb config --linux-packages "linux-image linux-header"

    4.7 Building and using an HDD image

    Building an HDD image is similar to an ISO hybrid one in all respects except you specify -b hdd and the resulting filename is binary.img which cannot be burnt to optical media. It is suitable for booting from USB sticks, USB hard drives, and various other portable storage devices. Normally, an ISO hybrid image can be used for this purpose instead, but if you have a BIOS which does not handle hybrid images properly, you need an HDD image.

    Note: if you created an ISO hybrid image with the previous example, you will need to clean up your working directory with the lb clean command (see The lb clean command):

    # lb clean --binary

    Run the lb config command as before, except this time specifying the HDD image type:

    $ lb config -b hdd

    Now build the image with the lb build command:

    # lb build

    When the build finishes, a binary.img file should be present in the current directory.

    The generated binary image contains a VFAT partition and the syslinux bootloader, ready to be directly written on a USB device. Once again, using an HDD image is just like using an ISO hybrid one on USB. Follow the instructions in Using an ISO hybrid live image, except use the filename binary.img instead of binary.hybrid.iso.

    Likewise, to test an HDD image with Qemu, install qemu as described above in Testing an ISO image with QEMU. Then run kvm or qemu, depending on which version your host system needs, specifying binary.img as the first hard drive.

    $ kvm -hda binary.img

    4.8 Building a netboot image

    The following sequence of commands will create a basic netboot image containing a default live system without It is suitable for booting over the network.

    Note: if you performed any previous examples, you will need to clean up your working directory with the lb clean command:

    # lb clean

    In this specific case, a lb clean --binary would be not enough to clean up the necessary stages. The cause for this is that in netboot setups, a different initramfs configuration needs to be used which live-build performs automatically when building netboot images. Since the initramfs creation belongs to the chroot stage, switching to netboot in an existing build directory means to rebuild the chroot stage too. Therefore, lb clean (which will remove the chroot stage, too) needs to be used.

    Run the lb config command as follows to configure your image for netbooting:

    $ lb config -b netboot --net-root-path "/srv/debian-live" --net-root-server ""

    In contrast with the ISO and HDD images, netbooting does not, itself, serve the filesystem image to the client, so the files must be served via NFS. Different network filesystems can be chosen through lb config. The --net-root-path and --net-root-server options specify the location and server, respectively, of the NFS server where the filesytem image will be located at boot time. Make sure these are set to suitable values for your network and server.

    Now build the image with the lb build command:

    # lb build

    In a network boot, the client runs a small piece of software which usually resides on the EPROM of the Ethernet card. This program sends a DHCP request to get an IP address and information about what to do next. Typically, the next step is getting a higher level bootloader via the TFTP protocol. That could be pxelinux, GRUB, or even boot directly to an operating system like Linux.

    For example, if you unpack the generated binary.netboot.tar archive in the /srv/debian-live directory, you'll find the filesystem image in live/filesystem.squashfs and the kernel, initrd and pxelinux bootloader in tftpboot/debian-live/i386.

    We must now configure three services on the server to enable netboot: the DHCP server, the TFTP server and the NFS server.

    4.8.1 DHCP server

    We must configure our network's DHCP server to be sure to give an IP address to the netbooting client system, and to advertise the location of the PXE bootloader.

    Here is an example for inspiration, written for the ISC DHCP server isc-dhcp-server in the /etc/dhcp/dhcpd.conf configuration file:

    # /etc/dhcp/dhcpd.conf - configuration file for isc-dhcp-server

    ddns-update-style none;

    option domain-name "";
    option domain-name-servers,;

    default-lease-time 600;
    max-lease-time 7200;

    log-facility local7;

    subnet netmask {
       next-server servername;
       filename "pxelinux.0";

    4.8.2 TFTP server

    This serves the kernel and initial ramdisk to the system at run time.

    You should install the tftpd-hpa package. It can serve all files contained inside a root directory, usually /srv/tftp. To let it serve files inside /srv/debian-live/tftpboot, run as root the following command:

    # dpkg-reconfigure -plow tftpd-hpa

    and fill in the new tftp server directory when being asked about it.

    4.8.3 NFS server

    Once the guest computer has downloaded and booted a Linux kernel and loaded its initrd, it will try to mount the Live filesystem image through a NFS server.

    You need to install the nfs-kernel-server package.

    Then, make the filesystem image available through NFS by adding a line like the following to /etc/exports:

    /srv/debian-live *(ro,async,no_root_squash,no_subtree_check)

    and tell the NFS server about this new export with the following command:

    # exportfs -rv

    Setting up these three services can be a little tricky. You might need some patience to get all of them working together. For more information, see the syslinux wiki at ‹› or the Debian Installer Manual's TFTP Net Booting section at ‹›. They might help, as their processes are very similar.

    4.8.4 Netboot testing HowTo

    Netboot image creation is made easy with live-build, but testing the images on physical machines can be really time consuming.

    To make our life easier, we can use virtualization.

    4.8.5 Qemu

  • Install qemu, bridge-utils, sudo.
  • Edit /etc/qemu-ifup:

    sudo -p "Password for $0:" /sbin/ifconfig $1
    echo "Executing /etc/qemu-ifup"
    echo "Bringing up $1 for bridged mode..."
    sudo /sbin/ifconfig $1 promisc up
    echo "Adding $1 to br0..."
    sudo /usr/sbin/brctl addif br0 $1
    sleep 2

    Get, or build a grub-floppy-netboot.

    Launch qemu with "-net nic,vlan=0 -net tap,vlan=0,ifname=tun0"