1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
|
:B~ Customizing run time behaviours
1~customizing-run-time-behaviours Customizing run time behaviours
All configuration that is done during run time is done by live-config. Here
are some 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.
2~ Customizing the live user
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}#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 to a file in the
#{config/chroot_local-preseed}# directory:
code{
user-setup passwd/user-default-groups string audio cdrom dip floppy video plugdev netdev powerdev scanner bluetooth fuse
}code
2~customizing-locale-and-language Customizing locale and language
When the live system boots, language is involved in three steps:
_* the locale generation
_* setting the keyboard layout for the console
_* setting the keyboard layout for X
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.
code{
$ lb config --bootappend-live "locales=de_CH.UTF-8"
}code
This parameter can also be used at the kernel command line. You can specify
a locale by a full #{language_country.encoding}# word.
Both the console and X keyboard configuration depend on the
#{keyboard-layouts}# parameter of the #{--bootappend-live}# option. Valid
options for X keyboard layouts can be found in
#{/usr/share/X11/xkb/rules/base.xml}# (rather limited to two-letters country
codes). To find the value (the two characters) corresponding to a language
try searching for the english name of the nation where the language is
spoken, e.g:
code{
$ grep -i sweden -C3 /usr/share/X11/xkb/rules/base.xml | grep name
<name>se</name>
}code
To get the locale files for German and Swiss German keyboard layout in X
use:
code{
$ lb config --bootappend-live "locales=de_CH.UTF-8 keyboard-layouts=ch"
}code
A list of the valid values of the keyboards for the console can be figured
with the following command:
code{
$ for i in $(find /usr/share/keymaps/ -iname "*kmap.gz"); \
do basename $i | head -c -9; echo; done | sort | less
}code
Alternatively, you can use the #{console-setup}# package, a tool to let you
configure console layout using X (XKB) definitions; you can then set your
keyboard layout more precisely with #{keyboard-layouts}#,
#{keyboard-variant}#, #{keyboard-options}# and #{keyboard-model}# variables;
live-boot will use also these parameters for X configuration. For example,
to set up a French system with a French-Dvorak layout (called Bepo) on a
TypeMatrix keyboard, both in console and X11, use:
code{
$ lb config --bootappend-live \
"locales=fr_FR.UTF-8 keyboard-layouts=fr keyboard-variant=bepo keyboard-model=tm2030usb"
}code
2~persistence Persistence
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 could work it could be handy to know that even if the
system is booted and run from read-only media, modification 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 a Hard Disk, a USB key, 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: #{persistent}#.
3~ Full persistence
By 'full persistence' it is meant that instead of using a tmpfs for storing
modifications to the read-only media (with the copy-on-write, COW, system) a
writable partition is used. In order to use this feature a partition with a
clean writable supported filesystem on it labeled "live-rw" must be attached
on the system at boot time and the system must be started with the boot
parameter 'persistent'. This partition could be an ext2 partition on the
hard disk or on a usb key created with, e.g.:
code{
# mkfs.ext2 -L live-rw /dev/sdb1
}code
If you already have a partition on your device, you could just change the
label with one of the following:
code{
# tune2fs -L live-rw /dev/sdb1 # for ext2,3,4 filesystems
# dosfslabel /dev/sdb1 live-rw # for a fat filesystem
}code
But since live system users cannot always use a hard drive partition, and
considering that most USB keys have poor write speeds, 'full' persistence
could be also used with just image files, so you could create a file
representing a partition and put this image file even on a NTFS partition of
a foreign OS, with something like:
code{
$ dd if=/dev/null of=live-rw bs=1G seek=1 # for a 1GB sized image file
$ /sbin/mkfs.ext2 -F live-rw
}code
Then copy the #{live-rw}# file to a writable partition and reboot with the
boot parameter 'persistent'.
3~ Home automounting
If during the boot a partition (filesystem) image file or a partition
labeled #{home-rw}# is discovered, this filesystem will be directly mounted
as #{/home}#, thus permitting persistence of files that belong to e.g. the
default user. It can be combined with full persistence.
3~ Snapshots
Snapshots are collections of files and directories which are not mounted
while running but which are copied from a persistent device to the system
(tmpfs) at boot and which are resynced at reboot/shutdown of the system. The
content of a snapshot could reside on a partition or an image file (like the
above mentioned types) labeled #{live-sn}#, but it defaults to a simple cpio
archive named #{live-sn.cpio.gz}#. As above, at boot time, the block devices
connected to the system are traversed to see if a partition or a file named
like that could be found. A power interruption during run time could lead to
data loss, hence a tool invoked #{live-snapshot --refresh}# could be called
to sync important changes. This type of persistence, since it does not write
continuously to the persistent media, is the most flash-based device
friendly and the fastest of all the persistence systems.
A /home version of snapshot exists too and its label is #{home-sn.*}#; it
works the same as the main snapshot but it is only applied to /home.
Snapshots cannot currently handle file deletion but full persistence and
home automounting can.
3~ Persistent SubText
If a user would need multiple persistent storage of the same type for
different locations or testing, such as #{live-rw-nonwork}# and
#{live-rw-work}#, the boot parameter #{persistent-subtext}# used in
conjuntion with the boot parameter #{persistent}# will allow for multiple
but unique persistent media. An example would be if a user wanted to use a
persistent partition labeled #{live-sn-subText}# they would use the boot
parameters of: #{persistent}# #{persistent-subtext=subText}#.
3~ Partial remastering
The run-time modification of the tmpfs could be collected using
live-snapshot in a squashfs and added to the cd by remastering the iso in
the case of cd-r or adding a session to multisession cd/dvd(rw); live-boot
mounts all /live filesystem in order or with the module boot parameter.
|