forked from OSInside/kiwi-legacy
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathkiwi-doc-iso.xml
251 lines (232 loc) · 9.73 KB
/
kiwi-doc-iso.xml
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
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.docbook.org/xml/4.5/docbookx.dtd">
<chapter id="chap.iso">
<title>ISO Image—Live Systems</title>
<indexterm>
<primary>KIWI</primary>
<secondary>ISO image</secondary>
</indexterm>
<indexterm>
<primary>images</primary>
<secondary>ISO</secondary>
</indexterm>
<indexterm>
<primary>ISO images</primary>
</indexterm>
<para>A live system image is an operating System on CD or DVD. In
principle one can treat the CD/DVD as the hard disk of the system
with the restriction that you can’t write data on it. So as soon as
the media is plugged into the computer, the machine is able to boot
from that media. After some time one can login to the system and
work with it like on any other system. All write actions takes place
in RAM space and therefore all changes will be lost as soon as the
computer shuts down. </para>
<sect1 id="sec.iso.building">
<title>Building the suse-live-iso Example</title>
<para>
This example is based on openSUSE and includes the KDE desktop.
</para>
<screen><command>cd</command> /usr/share/doc/packages/kiwi/examples
==> select the example directory for the desired distribution change into it
<command>cd</command> suse-...
<command>kiwi</command> --build ./suse-live-iso -d /tmp/myiso-result --type iso</screen>
</sect1>
<sect1 id="sec.iso.using">
<title>Using the Image</title>
<para>There are two ways to use the generated ISO image: </para>
<itemizedlist>
<listitem>
<para>Burn the <filename class="extension">.iso</filename> file
on a CD or DVD with your preferred burn program. Plug in the
CD or DVD into a test computer and (re)boot the machine. Make
sure the computer boot from the CD drive as first boot device.
</para>
</listitem>
<listitem>
<para>Use a virtualization system to test the image directly.
Testing an iso can be done with any full virtual system for
example: </para>
<screen><command>cd</command> /tmp/myiso-result
<command>qemu</command> -cdrom ./suse-*-live-iso.*.iso</screen>
</listitem>
</itemizedlist>
</sect1>
<sect1 id="sec.iso.flavours">
<title>Flavours</title>
<para>
KIWI supports different filesystems and boot methods along
with the ISO image type. The provided example by default uses a
<systemitem class="filesystem">clicfs</systemitem> compressed
root filesystem. clicfs is a fuse user space filesystem which
reads in data from a compressed image and writes data into a
cow file which can exist in RAM or in persistent area on a disk.
The result is a full writable live-system. The flags attribute
in <filename>config.xml</filename> exists to be able to have the
following alternative solutions:
</para>
<variablelist>
<varlistentry>
<term><sgmltag class="attribute">flags</sgmltag>="<sgmltag
class="attvalue">compressed</sgmltag>"</term>
<listitem>
<para> Does filesystem compression with squashfs, but don’t
use an overlay filesystem for write support. A symbolic link
list is used instead and thus a split element is required in
<filename>config.xml</filename>. See the split mode
section below for details. </para>
</listitem>
</varlistentry>
<varlistentry>
<term><sgmltag class="attribute">flags</sgmltag>="<sgmltag
class="attvalue">clic|clic_udf</sgmltag>"</term>
<listitem>
<para> Creates a FUSE based <systemitem class="filesystem"
>clicfs</systemitem> image and allows write operations
into a cow file. In case of an ISO the write happens into a
ramdisk. If clic_udf is specified the the iso is created
with an udf filesystem and thus this allows to create
live systems bigger than 4G</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Flags Not Set</term>
<listitem>
<para>If no <sgmltag class="attribute">flags</sgmltag>
attribute is set no compressed filesystem, no overlay
filesystem will be used. The root tree will be directly part
of the ISO filesystem and the paths:
<filename>/bin</filename>, <filename>/boot</filename>,
<filename>/lib</filename>, <filename>/lib64</filename>,
<filename>/opt</filename>, <filename>/sbin</filename>, and
<filename>/usr</filename> will be read-only. </para>
</listitem>
</varlistentry>
</variablelist>
<sect2 id="sec.iso.split-mode">
<title>Split mode</title>
<indexterm>
<primary>KIWI</primary>
<secondary>split mode</secondary>
</indexterm>
<indexterm>
<primary>KIWI</primary>
<secondary>overlay filesystem</secondary>
</indexterm>
<para>If no overlay filesystem is in use but the image filesystem
is based on a compressed filesystem KIWI allows to setup which
files and directories should be writable in a so called split
section. In order to allow to login into the system, at least
the <filename class="directory">/var</filename> directory should
be writable. This is because the PAM authentication requires
to be able to report any login attempt to
<filename>/var/log/messages</filename> which therefore needs
to be writable. The following split section can be used if the
flag compressed is used: </para>
<screen><split>
<persistent>
<file name="/var"/>
<file name="/var/*"/>
<file name="/boot"/>
<file name="/boot/*"/>
<file name="/etc"/>
<file name="/etc/*"/>
<file name="/home"/>
<file name="/home/*"/>
<file name="/tmp"/>
<file name="/tmp/*"/>
</persistent>
</split></screen>
</sect2>
<sect2 id="sec.iso.hybrid-mode">
<title>Hybrid mode</title>
<indexterm>
<primary>KIWI</primary>
<secondary>hybrid mode</secondary>
</indexterm>
<indexterm>
<primary>KIWI</primary>
<secondary>USB sticks</secondary>
</indexterm>
<para>
A hybrid image is a iso image including a partition table and can
therefore be attached as a CD/DVD <emphasis>and</emphasis> as a
normal disk to the system. This has the advantage that a hybrid
iso live system can be burned to a CD/DVD as well as uploaded to
a USB stick. In order to activate the hybrid feature the hybrid
flag must be set to true as indicated below.
</para>
<screen><type image="iso" ... hybrid="true"/></screen>
</sect2>
</sect1>
<sect1>
<title>USB stick images</title>
<indexterm>
<primary>KIWI</primary>
<secondary>USB</secondary>
</indexterm>
<para>
kiwi supports two types of USB stick images. The first type which
are the hybrid ISO images and basically the same as the live ISO images
and the second type which are the OEM virtual disk images.
The deployment of both types can be performed from any OS including
Windows as long as a tool to dump data onto a disk device exists
and is used.
</para>
<sect2>
<title>ISO Hybrid stick</title>
<indexterm>
<primary>KIWI</primary>
<secondary>Hybrid stick</secondary>
</indexterm>
<para>
As indicated above a hybrid iso image also works as USB stick image.
If a hybrid iso is used like a disk image on a writable medium
like a USB stick it's possible to write into a persistent area on
the stick instead of the RAM. kiwi will create an additional ext2
partition to store that information on the disk if the attribute
hybridpersistent is set to true.
</para>
<screen><type image="iso" ... hybridpersistent="true"/></screen>
</sect2>
<sect2>
<title>OEM USB stick</title>
<indexterm>
<primary>KIWI</primary>
<secondary>OEM stick</secondary>
</indexterm>
<para> In contrast to the hybrid iso image it's also possible to
create a oem virtual disk image which is dumped on the stick.
The big advantage with this approach is, that it's possible to
create a stick which contains a live OS but also a data
partition for custom data. The data partition is a fat partition
also recognized by the Windows operating system. In order to
create such a Windows friendly stick one has to pass the option
<option>--fat-storage <size-in-MB></option>.
<screen><command>kiwi</command> --create ... --fat-storage 500</screen>
If this option is set kiwi will use the syslinux bootloader for
the image as well as the first partition as fat partition of the
specified size. The live OS itself will live in a LVM which
allows easy manipulation of the logical root volume. For further
information about the OEM image type please refer to the OEM
chapter <xref linkend="chap.oem"/>
</para>
<sect3>
<title>OEM compressed / readonly USB stick</title>
<indexterm>
<primary>KIWI</primary>
<secondary>compressed root</secondary>
</indexterm>
<para> If a compressed filesystem type like clicfs is used for the
image root directory it's also possible to allow persistent
writing on the USB stick or alternatively disallow that and
let all write actions perfom in RAM only. kiwi provides the
type attribute ramonly for this purpose. So in order to create
a read-only oem stick with compressed root filesystem the
following type section is required:
<screen><type image="oem" filesystem="clicfs" ramonly="true" .../></screen>
</para>
</sect3>
</sect2>
</sect1>
</chapter>