- System Boot Components
contains the components that configure a live system during the
boot process (early userspace).
live-boot is a hook for the initramfs-tools, used to generate a initramfs
capable to boot live systems, such as those created by live-helper
This includes the Live systems ISOs, netboot tarballs, and usb stick images.
At boot time it will look for a (read-only) medium containing a
"/live" directory where a root filesystems (often a compressed
filesystem image like squashfs) is stored. If found, it will create a writable
environment, using aufs, to boot the system from.
can be configured through a boot parameter or a configuration
To configure the live-boot parameters used by default in a live image, see the
--bootappend-live option in the lb_config(1)
is only activated if 'boot=live' was used as a kernel
In addition, there are some more boot parameters to influence the behaviour, see
can be configured (but not activated) through configuration
files. Those files can be placed either in the root filesystem itself
(/etc/live/boot.conf, /etc/live/boot/*), or on the live media (live/boot.conf,
currently features the following parameters.
- Set the accessibility level for physically or visually
impaired users. ACCESS must be one of v1, v2, v3, m1, or m2. v1=lesser
visual impairment, v2=moderate visual impairment, v3=blindness, m1=minor
motor difficulties, m2=moderate motor difficulties.
- Set the default console to be used with the
"live-getty" option. Example:
- Makes initramfs boot process more verbose.
Without setting debug to a value the messages may not be shown.
- Another form of netboot by downloading a squashfs image
from a given URL. The fetch method copies the image to RAM and the httpfs
method uses FUSE and httpfs2 to mount the image in place. Copying to RAM
requires more memory and might take a long time for large images. However,
it is more likely to work correctly because it does not require networking
afterwards and the system operates faster once booted because it does not
require to contact the server anymore.
Due to current limitations in busybox's wget and DNS resolution, an URL can
not contain a hostname but an IP address only.
Not working: http://example.com/path/to/your_filesystem.squashfs
Also note that therefore it's currently not possible to fetch an image from
a name-based virtualhost of an httpd if it is sharing the IP address with
the main httpd instance.
You may also use the live ISO image in place of the squashfs image.
- Boot from an iSCSI target that has an ISO or disk live
image as one of its LUNs. The specified target is searched for a LUN which
looks like a live medium. If you use the iscsitarget software iSCSI
target solution your ietd.conf might look like this:
# The target-name you specify in the iscsi= parameter
Lun 0 Path=<path-to-your-live-image.iso>,Type=fileio,IOMode=ro
# If you want to boot multiple machines you might want to look at tuning
some parameters like
# Wthreads or MaxConnections
- Look for the specified ISO file on all disks where it
usually looks for the .squashfs file (so you don't have to know the device
name as in fromiso=....).
- Allows to use a filesystem from within an ISO image that's
available on live-media.
- Do not check that any UUID embedded in the initramfs
matches the discovered medium. live-boot may be told to generate a UUID by
setting LIVE_GENERATE_UUID=1 when building the initramfs.
- If specified, an MD5 sum is calculated on the live media
during boot and compared to the value found in md5sum.txt found in the
root directory of the live media.
- Let you specify the name(s) and the options of the
interface(s) that should be configured at boot time. Do not specify this
if you want to use dhcp (default). It will be changed in a future release
to mimick official kernel boot param specification (e.g.
- If this variable is set, dhcp and static configuration are
just skipped and the system will use the (must be) media-preconfigured
- If you specify one of this two equivalent forms, live-boot
will first try to find this device for the "/live" directory
where the read-only root filesystem should reside. If it did not find
something usable, the normal scan for block devices is performed.
Instead of specifing an actual device name, the keyword 'removable' can be
used to limit the search of acceptable live media to removable type only.
Note that if you want to further restrict the media to usb mass storage
only, you can use the 'removable-usb' keyword.
- live-boot will mount the encrypted rootfs TYPE, asking the
passphrase, useful to build paranoid live systems :-). TYPE supported so
far is "aes" for loop-aes encryption type.
- This way you could tell live-boot that your image starts at
offset BYTES in the above specified or autodiscovered device, this could
be useful to hide the live system ISO or image inside another ISO or
image, to create "clean" images.
- Sets the path to the live filesystem on the medium. By
default, it is set to '/live' and you should not change that unless you
have customized your media accordingly.
- Set the timeout in seconds for the device specified by
"live-media=" to become ready before giving up.
- Instead of using the default optional file
"filesystem.module" (see below) another file could be specified
without the extension ".module"; it should be placed on
"/live" directory of the live medium.
- This tells live-boot to perform a network mount. The
parameter "nfsroot=" (with optional "nfsopts="),
should specify where is the location of the root filesystem. With no args,
will try cifs first, and if it fails nfs.
- This lets you specify custom nfs options.
- This parameter disables the default disabling of filesystem
checks in /etc/fstab. If you have static filesystems on your harddisk and
you want them to be checked at boot time, use this parameter, otherwise
they are skipped.
- disables the "persistence" feature, useful if the
bootloader (like syslinux) has been installed with persistence
- Do not prompt to eject the live medium.
- This parameter allows to set a custom ramdisk size (it's
the '-o size' option of tmpfs mount). By default, there is no ramdisk size
set, so the default of mount applies (currently 50% of available RAM).
Note that this option has currently no effect when booting with
- This parameter enables usage of local swap partitions.
- live-boot will probe devices for persistence media. These
can be partitions (with the correct GPT name), filesystems (with the
correct label) or image files (with the correct file name). Overlays are
labeled/named "persistence" (see persistence.conf(5)).
Overlay image files are named "persistence".
- persistence-encryption=TYPE1,TYPE2 ...
- This option determines which types of encryption that we
allow to be used when probing devices for persistence media. If
"none" is in the list, we allow unencrypted media; if
"luks" is in the list, we allow LUKS-encrypted media. Whenever a
device containing encrypted media is probed the user will be prompted for
the passphrase. The default value is "none".
- If you specify the keyword 'removable', live-boot will try
to find persistence partitions on removable media only. Note that if you
want to further restrict the media to usb mass storage only, you can use
the 'removable-usb' keyword.
- persistence-method=TYPE1,TYPE2 ...
- This option determines which types of persistence media we
allow. If "overlay" is in the list, we consider overlays (i.e.
"live-rw" and "home-rw"). The default is
- live-boot will look for persistency files in the root
directory of a partition, with this parameter, the path can be configured
so that you can have multiple directories on the same partition to store
- Filesystem changes are not saved back to persistence media.
In particular, overlays and netboot NFS mounts are mounted read-only.
- persistence-storage=TYPE1,TYPE2 ...
- This option determines which types of persistence storage
to consider when probing for persistence media. If "filesystem"
is in the list, filesystems with matching labels will be used; if
"file" is in the list, all filesystems will be probed for
archives and image files with matching filenames. The default is
- live-boot will use the name "LABEL" instead of
"persistence" when searching for persistent storage. LABEL can
be any valid filename, partition label, or GPT name.
- This option causes live-boot to reboot without attempting
to eject the media and without asking the user to remove the boot
- This parameter will make live-boot to show on "/"
the ro filesystems (mostly compressed) on "/lib/live". This is
not enabled by default because could lead to problems by applications like
"mono" which store binary paths on installation.
- If you boot with the normal quiet parameter, live-boot
hides most messages of its own. When adding silent, it hides all.
- Adding this parameter, live-boot will try to copy the
entire read-only media to the specified device before mounting the root
filesystem. It probably needs a lot of free space. Subsequent boots should
then skip this step and just specify the "live-media=DEVICE"
boot parameter with the same DEVICE used this time.
- Adding this parameter, live-boot will try to copy the whole
read-only media to the computer's RAM before mounting the root filesystem.
This could need a lot of ram, according to the space used by the read-only
- By default, live-boot uses aufs. With this parameter, you
can switch to unionfs.
- Some variables can be configured via this config file
(inside the live system).
- This optional file (inside the live media) contains a list
of white-space or carriage-return-separated file names corresponding to
disk images in the "/live" directory. If this file exists, only
images listed here will be merged into the root aufs, and they will be
loaded in the order listed here. The first entry in this file will be the
"lowest" point in the aufs, and the last file in this list will
be on the "top" of the aufs, directly below /overlay. Without
this file, any images in the "/live" directory are loaded in
More information about live-boot 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-boot package in the
Bug Tracking System at < http://bugs.debian.org/
> or by writing a
mail to the Live Systems mailing list at <
live-boot was written by Daniel Baumann <