All configuration that is done during run time is done by live-config. Here are some of the most common options of live-config that users are interested in. A full list of all possibilities can be found in the manpage of live-config.
One important consideration is that the live user is created by live-boot at boot time, not by live-build at build time. This not only influences where materials relating to the live user are introduced in your build, as discussed in Live/chroot local includes, but also any groups and permissions associated with the live user.
You can specify additional groups that the live user will belong to by preseeding the passwd/user-default-groups debconf value. For example, to add the live user to the fuse group, add the following preseed under config/preseed/ for the chroot stage:
$ lb config
$ echo user-setup passwd/user-default-groups string audio cdrom \
dip floppy video plugdev netdev powerdev scanner bluetooth fuse \
>> config/preseed/my.preseed.chroot
It is also possible to change the default username "user" and the default password "live". If you want to do that for any reason, you can easily achieve it as follows:
To change the default username you can simply specify it in your config:
$ lb config --bootappend-live "username=live-user"
One possible way of changing the default password is by means of a hook as described in Boot-time hooks. In order to do that you can use the "passwd" hook from /usr/share/doc/live-config/examples/hooks, prefix it accordingly (e.g. 2000-passwd) and add it to config/includes.chroot/lib/live/config/
When the live system boots, language is involved in two steps:
The default locale when building a Live system is locales=en_US.UTF-8. To define the locale that should be generated, use the locales parameter in the --bootappend-live option of lb config, e.g.
$ lb config --bootappend-live "locales=de_CH.UTF-8"
Multiple locales may be specified as a comma-delimited list.
This parameter, as well as the keyboard configuration parameters indicated below, can also be used at the kernel command line. You can specify a locale by language_country (in which case the default encoding is used) or the full language_country.encoding word. A list of supported locales and the encoding for each can be found in /usr/share/i18n/SUPPORTED.
Both the console and X keyboard configuration are performed by live-config using the console-setup package. To configure them, use the keyboard-layouts, keyboard-variants, keyboard-options and keyboard-model boot parameters via the --bootappend-live option. Valid options for these can be found in /usr/share/X11/xkb/rules/base.lst. To find layouts and variants for a given language, try searching for the English name of the language and/or the country where the language is spoken, e.g:
$ egrep -i '(^!|german.*switzerland)' /usr/share/X11/xkb/rules/base.lst
! model
! layout
ch German (Switzerland)
! variant
legacy ch: German (Switzerland, legacy)
de_nodeadkeys ch: German (Switzerland, eliminate dead keys)
de_sundeadkeys ch: German (Switzerland, Sun dead keys)
de_mac ch: German (Switzerland, Macintosh)
! option
Note that each variant lists the layout to which it applies in the description.
Often, only the layout needs to be configured. For example, to get the locale files for German and Swiss German keyboard layout in X use:
$ lb config --bootappend-live "locales=de_CH.UTF-8 keyboard-layouts=ch"
However, for very specific use cases, you may wish to include other parameters. For example, to set up a French system with a French-Dvorak layout (called Bepo) on a TypeMatrix EZ-Reach 2030 USB keyboard, use:
$ lb config --bootappend-live \
"locales=fr_FR.UTF-8 keyboard-layouts=fr keyboard-variants=bepo keyboard-model=tm2030usb"
Multiple values may be specified as comma-delimited lists for each of the keyboard-* options, with the exception of keyboard-model, which accepts only one value. Please see the keyboard(5) man page for details and examples of XKBMODEL, XKBLAYOUT, XKBVARIANT and XKBOPTIONS variables. If multiple keyboard-variants values are given, they will be matched one-to-one with keyboard-layouts values (see setxkbmap(1) -variant option). Empty values are allowed; e.g. to define two layouts, the default being US QWERTY and the other being US Dvorak, use:
$ lb config --bootappend-live \
"keyboard-layouts=us,us keyboard-variants=,dvorak"
A live cd paradigm is a pre-installed system which runs from read-only media, like a cdrom, where writes and modifications do not survive reboots of the host hardware which runs it.
A Debian Live system is a generalization of this paradigm and thus supports other media in addition to CDs; but still, in its default behaviour, it should be considered read-only and all the run-time evolutions of the system are lost at shutdown.
'Persistence' is a common name for different kinds of solutions for saving across reboots some, or all, of this run-time evolution of the system. To understand how it works it would be handy to know that even if the system is booted and run from read-only media, modifications to the files and directories are written on writable media, typically a ram disk (tmpfs) and ram disks' data do not survive reboots.
The data stored on this ramdisk should be saved on a writable persistent medium like local storage media, a network share or even a session of a multisession (re)writable CD/DVD. All these media are supported in Debian Live in different ways, and all but the last one require a special boot parameter to be specified at boot time: persistence.
If the boot parameter persistence is set (and nopersistence is not set), local storage media (e.g. hard disks, USB drives) will be probed for persistence volumes during boot. It is possible to restrict which types of persistence volumes to use by specifying certain boot parameters described in the live-boot(7) man page. A persistence volume is any of the following:
The volume label for overlays must be persistence. And in order to fully customize the volume's persistence there must be a file named live-persistence.conf. See The live-persistence.conf file
Here are some examples of how to prepare a volume to be used for persistence. It can be, for instance, an ext4 partition on a hard disk or on a usb key created with, e.g.:
# mkfs.ext4 -L persistence /dev/sdb1
See also Using the space left on a USB stick.
If you already have a partition on your device, you could just change the label with one of the following:
# tune2fs -L persistence /dev/sdb1 # for ext2,3,4 filesystems
Here's an example of how to create an ext4-based image file used for persistence:
$ dd if=/dev/null of=persistence bs=1G seek=1 # for a 1GB sized image file
$ /sbin/mkfs.ext4 -F persistence
Then copy the persistence file to the root of a writable partition.
A volume with the label persistence can be configured to make arbitrary directories persistent. The file live-persistence.conf, located on the volume's filesystem root, controls which directories it makes persistent, and in which way.
How custom overlay mounts are configured is described in full detail in the live-persistence.conf(5) man page, but a simple example should be sufficient for most uses. Let's say we want to make our home directory and APT cache persistent in an ext4 filesystem on the /dev/sdb1 partition:
# mkfs.ext4 -L persistence /dev/sdb1
# mount -t ext4 /dev/sdb1 /mnt
# echo "/home" >> /mnt/live-persistence.conf
# echo "/var/cache/apt" >> /mnt/live-persistence.conf
Then we reboot. During the first boot the contents of /home and /var/cache/apt will be copied into the persistence volume, and from then on all changes to these directories will live in the persistence volume. Please note that any paths listed in the live-persistence.conf file cannot contain white spaces or the special . and .. path components. Also, neither /live (or any of its sub-directories) nor / can be made persistent using custom mounts.
Several different custom overlay volumes (with their own live-persistence.conf files) can be used at the same time, but if several volumes make the same directory persistent, only one of them will be used. If any two mounts are "nested" (i.e. one is a sub-directory of the other) the parent will be mounted before the child so no mount will be hidden by the other. Nested custom mounts are problematic if they are listed in the same live-persistence.conf file. See the live-persistence.conf(5) man page for how to handle that case if you really need it (hint: you usually don't).
If a user would need multiple persistence store of the same type for different locations or testing, such as persistence-nonwork and persistence-work, the boot parameter persistence-label used in conjunction with the boot parameter persistence will allow for multiple but unique persistence media. An example would be if a user wanted to use a persistence partition labeled persistence-subText they would use the boot parameters of: persistence persistence-label=subText.