aboutsummaryrefslogtreecommitdiffhomepage
path: root/markup/pod/live-manual/media/text/ro/user_basics.ssi
blob: 92371a8941b32ff4eff6f9558261b8da99c4e6e9 (plain)
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
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
:B~ The basics

1~the-basics 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 includes detailed
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 already familiar 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.

The section finishes with a quick introduction to {webbooting}#webbooting
which is, perhaps, the easiest way of using different images for different
purposes, switching from one to the other as needed using the internet as a
means.

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

2~what-is-live 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}#terms).

With live systems, it's an 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 live system image
size. Note that it is read-only. So, during boot the 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}#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.).

2~downloading-prebuilt-images 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}#clone-configuration-via-git and
official stable releases are published at
https://www.debian.org/CD/live/. In addition, older and upcoming releases,
and unofficial images containing non-free firmware and drivers are available
at http://live-systems.org/cdimage/release/.

2~using-web-builder Using the web live image builder

As a service to the community, we run a web-based live image builder service
at http://live-systems.org/build/. 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}#contact,
providing us with the link to your build.

3~ 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 #{586}# 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}#contact 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.

2~building-iso-hybrid 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 X.org. 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.

code{

 $ mkdir live-default && cd live-default

}code

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

code{

 $ lb config

}code

No parameters are passed to these commands, so defaults for all of their
various options will be used. See {The lb config command}#lb-config for more
details.

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

code{

 # lb build

}code

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
#{live-image-i386.hybrid.iso}# image file, ready to use, in the current
directory.

*{Note:}* If you are building on an amd64 system the name of the resulting image will be #{live-image-amd64.hybrid.iso}#. Keep in mind this naming convention throughout the manual.

2~using-iso-hybrid Using an ISO hybrid live image

After either building or downloading an ISO hybrid image, which can be
obtained at https://www.debian.org/CD/live/, 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.

3~burning-iso-image 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:

code{

 # apt-get install xorriso
 $ xorriso -as cdrecord -v dev=/dev/sr0 blank=as_needed live-image-i386.hybrid.iso

}code

3~copying-iso-hybrid-to-usb Copying an ISO hybrid image to a USB stick

ISO images prepared with #{xorriso}#, can be simply copied to a USB stick
with the #{cp}# 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 #{cp}#
command to copy the image to the stick.  *{This will definitely overwrite
any previous contents on your stick!}*

code{

 $ cp live-image-i386.hybrid.iso ${USBSTICK}
 $ sync

}code

*{Note:}* The /{sync}/ command is useful to ensure that all the data, which is stored in memory by the kernel while copying the image, is written to the USB stick.

3~using-usb-extra-space Using the space left on a USB stick

After copying the #{live-image-i386.hybrid.iso}# to a USB stick, the first
partition on the device will be filled up by the live system. To use the
remaining free space, use a partitioning tool such as /{gparted}/ or
/{parted}/ to create a new partition on the stick.

code{

 # gparted ${USBSTICK}

}code

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.

code{

 # mkfs.ext4 ${PARTITION}

}code

*{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}#contact, but it seems there are no easy answers.

*{Remember: Every time you install a new live-image-i386.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.}*

3~booting-live-medium 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 a #{standard}# flavour {prebuilt
image}#downloading-prebuilt-images, you should be automatically logged in on
the console to the #{user}# account and see a shell prompt, ready to use.

2~using-virtual-machine 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.

3~testing-iso-with-qemu 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}#.

code{

 # apt-get install qemu-kvm qemu-utils

}code

Booting an ISO image is simple:

code{

 $ kvm -cdrom live-image-i386.hybrid.iso

}code

See the man pages for more details.

3~testing-iso-with-virtualbox Testing an ISO image with VirtualBox

In order to test the ISO with /{virtualbox}/:

code{

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

}code

Create a new virtual machine, change the storage settings to use
#{live-image-i386.hybrid.iso}# as the CD/DVD device, and start the machine.

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

code{

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

}code

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.

code{

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

}code

2~using-hdd-image 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 #{live-image-i386.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):

code{

 # lb clean --binary

}code

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

code{

 $ lb config -b hdd

}code

Now build the image with the #{lb build}# command:

code{

 # lb build

}code

When the build finishes, a #{live-image-i386.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}#using-iso-hybrid, except
use the filename #{live-image-i386.img}# instead of
#{live-image-i386.hybrid.iso}#.

Likewise, to test an HDD image with Qemu, install /{qemu}/ as described
above in {Testing an ISO image with QEMU}#testing-iso-with-qemu. Then run
#{kvm}# or #{qemu}#, depending on which version your host system needs,
specifying #{live-image-i386.img}# as the first hard drive.

code{

 $ kvm -hda live-image-i386.img

}code

2~building-netboot-image Building a netboot image

The following sequence of commands will create a basic netboot image
containing a default live system without X.org. 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:

code{

 # lb clean

}code

In this specific case, a #{lb clean --binary}# would not be 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:

code{

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

}code

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 filesystem 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:

code{

 # lb build

}code

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 #{live-image-i386.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/}#.

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

3~ 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:

code{

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

 ddns-update-style none;

 option domain-name "example.org";
 option domain-name-servers ns1.example.org, ns2.example.org;

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

 log-facility local7;

 subnet 192.168.0.0 netmask 255.255.255.0 {
   range 192.168.0.1 192.168.0.254;
   filename "pxelinux.0";
   next-server 192.168.0.2;
   option subnet-mask 255.255.255.0;
   option broadcast-address 192.168.0.255;
   option routers 192.168.0.1;
}

}code

3~ 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:

code{

 # dpkg-reconfigure -plow tftpd-hpa

}code

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

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}#:

code{

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

}code

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

code{

 # exportfs -rv

}code

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 http://www.syslinux.org/wiki/index.php/PXELINUX or the
Debian Installer Manual's TFTP Net Booting section at
http://d-i.alioth.debian.org/manual/en.i386/ch04s05.html. They might help,
as their processes are very similar.

3~ 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.

3~ Qemu

_* Install /{qemu}/, /{bridge-utils}/, /{sudo}/.

Edit #{/etc/qemu-ifup}#:

code{

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

}code

Get, or build a #{grub-floppy-netboot}#.

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

2~webbooting Webbooting

Webbooting is a convenient way of retrieving and booting live systems using
the internet as a means. The requirements for webbooting are very few. On
the one hand, you need a medium with a bootloader, an initial ramdisk and a
kernel. On the other hand, a web server to store the squashfs files which
contain the filesystem.

3~ Getting the webboot files

As usual, you can build the images yourself or use the prebuilt files, which
are available on the project's homepage at http://live-systems.org/. Using
prebuilt images would be handy for doing initial testing until one can fine
tune their own needs. If you have built a live image you will find the files
needed for webbooting in the build directory under #{binary/live/}#. The
files are called #{vmlinuz}#, #{initrd.img}# and #{filesystem.squashfs}#.

It is also possible to extract those files from an already existing iso
image. In order to achieve that, loopback mount the image as follows:

code{

 # mount -o loop image.iso /mnt

}code

The files are to be found under the #{live/}# directory. In this specific
case, it would be #{/mnt/live/}#. This method has the disadvantage that you
need to be root to be able to mount the image. However, it has the advantage
that it is easily scriptable and thus, easily automatized.

But undoubtedly, the easiest way of extracting the files from an iso image
and uploading it to the web server at the same time, is using the midnight
commander or /{mc}/. If you have the /{genisoimage}/ package installed, the
two-pane file manager allows you to browse the contents of an iso file in
one pane and upload the files via ftp in the other pane. Even though this
method requires manual work, it does not require root privileges.

3~ Booting webboot images

While some users will prefer virtualization to test webbooting, we refer to
real hardware here to match the following possible use case which should
only be considered as an example.

In order to boot a webboot image it is enough to have the components
mentioned above, i.e. #{vmlinuz}# and #{initrd.img}# in a usb stick inside a
directory named #{live/}# and install syslinux as bootloader. Then boot from
the usb stick and type #{fetch=URL/PATH/TO/FILE}# at the boot
options. live-boot will retrieve the squashfs file and store it into
ram. This way, it is possible to use the downloaded compressed filesystem as
a regular live system. For example:

code{

 append boot=live components fetch=http://192.168.2.50/images/webboot/filesystem.squashfs

}code

*{Use case:}* You have a web server in which you have stored two squashfs files, one which contains a full desktop, like for example gnome, and a standard one. If you need a graphical environment for one machine, you can plug your usb stick in and webboot the gnome image. If you need one of the tools included in the second type of image, perhaps for another machine, you can webboot the standard one.