Live システムマニュアル

About

このマニュアルについて

1. このマニュアルについて

1.1 せっかちな人向け
1.2 用語
1.3 著者
1.4 この文書への貢献
1.4.1 変更の適用
1.4.2 翻訳

Live システムプロジェクトへの貢献

2. Live システムプロジェクトについて

2.1 動機
2.1.1 現在の Live システムの問題点
2.1.2 自身の Live システムを作成する理由
2.2 哲学
2.2.1 Debian「main」の変更しないパッケージしか使いません
2.2.2 Live システム固有のパッケージ設定はありません
2.3 連絡先

ユーザ

Installation

3. Installation

3.1 Requirements
3.2 Installing live-build
3.2.1 From the Debian repository
3.2.2 From source
3.2.3 From 'snapshots'
3.3 Installing live-boot and live-config
3.3.1 From the Debian repository
3.3.2 From source
3.3.3 From 'snapshots'

基本

4. 基本

4.1 Live システムとは何?
4.2 ビルド済みイメージのダウンロード
4.3 ウェブ Live イメージビルダーの利用
4.3.1 ウェブビルダーの使い方と注意
4.4 最初の段階: ISO hybrid イメージのビルド
4.5 ISO hybrid Live イメージの利用
4.5.1 ISO イメージの実際のメディアへの書き込み
4.5.2 ISO hybrid イメージの USB メモリへのコピー
4.5.3 USB メモリの空きスペースの利用
4.5.4 Live メディアのブート
4.6 仮想マシンを利用したテスト
4.6.1 QEMU での ISO イメージのテスト
4.6.2 VirtualBox での ISO イメージのテスト
4.7 HDD イメージのビルド及び利用
4.8 netboot イメージのビルド
4.8.1 DHCP サーバ
4.8.2 TFTP サーバ
4.8.3 NFS サーバ
4.8.4 ネットワーク経由のブートをテストする方法
4.8.5 Qemu
4.9 ウェブブート
4.9.1 ウェブブートファイルの取得
4.9.2 ウェブブートイメージの起動

Overview of tools

5. Overview of tools

5.1 The live-build package
5.1.1 The lb config command
5.1.2 The lb build command
5.1.3 The lb clean command
5.2 The live-boot package
5.3 The live-config package

設定の管理

6. 設定の管理

6.1 設定変更への対応
6.1.1 自動化スクリプトを使う理由は? それは何をするもの?
6.1.2 自動化スクリプトの使用例
6.2 Git経由で公開されている設定の複製

収録内容の独自化

7. 独自化の概要

7.1 ビルド時とブート時の設定
7.2 ビルド段階
7.3 ファイルによる lb config の補完
7.4 独自化タスク

インストールするパッケージの独自化

8. インストールするパッケージの独自化

8.1 パッケージソース
8.1.1 ディストリビューション、アーカイブ領域とモード
8.1.2 ディストリビューションミラー
8.1.3 ビルド時に利用するディストリビューションミラー
8.1.4 実行時に利用するディストリビューションミラー
8.1.5 追加リポジトリ
8.2 Choosing packages to install
8.2.1 Package lists
8.2.2 Using metapackages
8.2.3 Local package lists
8.2.4 Local binary package lists
8.2.5 Generated package lists
8.2.6 Using conditionals inside package lists
8.2.7 Removing packages at install time
8.2.8 Desktop and language tasks
8.2.9 Kernel flavour and version
8.2.10 Custom kernels
8.3 Installing modified or third-party packages
8.3.1 Using packages.chroot to install custom packages
8.3.2 Using an APT repository to install custom packages
8.3.3 Custom packages and APT
8.4 Configuring APT at build time
8.4.1 Choosing apt or aptitude
8.4.2 Using a proxy with APT
8.4.3 Tweaking APT to save space
8.4.4 Passing options to apt or aptitude
8.4.5 APT pinning

収録内容の独自化

9. 収録内容の独自化

9.1 Includes
9.1.1 Live/chroot ローカルインクルード
9.1.2 バイナリローカルインクルード
9.2 フック
9.2.1 Live/chroot ローカルフック
9.2.2 ブート時フック
9.2.3 バイナリローカルフック
9.3 Debconf 質問の preseed

Customizing run time behaviours

10. Customizing run time behaviours

10.1 Customizing the live user
10.2 Customizing locale and language
10.3 Persistence
10.3.1 The persistence.conf file
10.3.2 Using more than one persistence store
10.4 Using persistence with encryption

バイナリイメージの独自化

11. バイナリイメージの独自化

11.1 ブートローダ
11.2 ISO メタ情報

Debian インストーラの独自化

12. Debian インストーラの独自化

12.1 Debian インストーラの種類
12.2 preseed による Debian インストーラの独自化
12.3 Debian インストーラの収録内容の独自化

プロジェクト

プロジェクトへの貢献

13. プロジェクトへの貢献

13.1 変更を加える

バグの報告

14. バグの報告

14.1 既知の問題
14.2 最初から再ビルド
14.3 最新のパッケージを使う
14.4 情報収集
14.5 可能であれば失敗している状況を分離する
14.6 正しいパッケージに対してバグを報告する
14.6.1 ビルド時のパッケージ収集中
14.6.2 ビルド時のパッケージインストール中
14.6.3 ブート時
14.6.4 実行時
14.7 調査してください
14.8 バグの報告先

コーディングスタイル

15. コーディングスタイル

15.1 互換性
15.2 インデント
15.3 改行
15.4 変数
15.5 その他

手順

16. 手順

16.1 主要リリース
16.2 ポイントリリース
16.2.1 ある Debian リリースの最後のポイントリリース
16.2.2 ポイントリリース告知用テンプレート

Git リポジトリ

17. Git リポジトリ

17.1 リポジトリを複数処理

18. 例

18.1 例の使用
18.2 チュートリアル 1: デフォルトイメージ
18.3 チュートリアル 2: ウェブブラウザユーティリティ
18.4 チュートリアル 3: 私的イメージ
18.4.1 最初の改訂
18.4.2 2回目の改訂
18.5 VNC 公衆クライアント
18.6 128MB USB メモリ向けの基本イメージ
18.7 地域化した GNOME デスクトップとインストーラ

付録

スタイルガイド

19. スタイルガイド

19.1 著者向けガイドライン
19.1.1 言語特性
19.1.2 手順
19.2 翻訳者向けガイドライン
19.2.1 翻訳の手がかり

Metadata

Live システムマニュアル

Customizing run time behaviours

10. Customizing run time behaviours

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 man page of live-config.

10.1 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, but also any groups and permissions associated with the live user.

You can specify additional groups that the live user will belong to by using any of the possibilities to configure live-config. For example, to add the live user to the fuse group, you can either add the following file in config/includes.chroot/etc/live/config/user-setup.conf:

LIVE_USER_DEFAULT_GROUPS="audio cdrom dip floppy video plugdev netdev powerdev scanner bluetooth fuse"

or use live-config.user-default-groups=audio,cdrom,dip,floppy,video,plugdev,netdev,powerdev,scanner,bluetooth,fuse as a boot parameter.

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 "boot=live components 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/

10.2 Customizing locale and language

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 "boot=live components 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 "boot=live components 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 \
     "boot=live components 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 \
     "boot=live components keyboard-layouts=us,us keyboard-variants=,dvorak"

10.3 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 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 live systems 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 but it will be ignored unless it contains in its root a file named persistence.conf which is used to fully customize the volume's persistence, this is to say, specifying the directories that you want to save in your persistence volume after a reboot. See The persistence.conf file for more details.

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 to be used for persistence:

$ dd if=/dev/null of=persistence bs=1 count=0 seek=1G # for a 1GB sized image file
$ /sbin/mkfs.ext4 -F persistence

Once the image file is created, as an example, to make /usr persistent but only saving the changes you make to that directory and not all the contents of /usr, you can use the "union" option. If the image file is located in your home directory, copy it to the root of your hard drive's filesystem and mount it in /mnt as follows:

# cp persistence /
# mount -t ext4 /persistence /mnt

Then, create the persistence.conf file adding content and unmount the image file.

# echo "/usr union" >> /mnt/persistence.conf
# umount /mnt

Now, reboot into your live medium with the boot parameter "persistence".

10.3.1 The persistence.conf file

A volume with the label persistence must be configured by means of the persistence.conf file to make arbitrary directories persistent. That file, 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 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/persistence.conf
# echo "/var/cache/apt" >> /mnt/persistence.conf
# umount /mnt

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 persistence.conf file cannot contain white spaces or the special . and .. path components. Also, neither /lib, /lib/live (or any of their sub-directories) nor / can be made persistent using custom mounts. As a workaround for this limitation you can add / union to your persistence.conf file to achieve full persistence.

10.3.2 Using more than one persistence store

There are different methods of using multiple persistence store for different use cases. For instance, using several volumes at the same time or selecting only one, among various, for very specific purposes.

Several different custom overlay volumes (with their own 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 persistence.conf file. See the persistence.conf(5) man page for how to handle that case if you really need it (hint: you usually don't).

One possible use case: If you wish to store the user data i.e. /home and the superuser data i.e. /root in different partitions, create two partitions with the persistence label and add a persistence.conf file in each one like this, # echo "/home" > persistence.conf for the first partition that will save the user's files and # echo "/root" > persistence.conf for the second partition which will store the superuser's files. Finally, use the persistence boot parameter.

If a user would need multiple persistence store of the same type for different locations or testing, such as private and 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 private for personal data like browser bookmarks or other types, they would use the boot parameters: persistence persistence-label=private. And to store work related data, like documents, research projects or other types, they would use the boot parameters: persistence persistence-label=work.

It is important to remember that each of these volumes, private and work, also needs a persistence.conf file in its root. The live-boot man page contains more information about how to use these labels with legacy names.

10.4 Using persistence with encryption

Using the persistence feature means that some sensible data might get exposed to risk. Especially if the persistent data is stored on a portable device such as a usb stick or an external hard drive. That is when encryption comes in handy. Even if the entire procedure might seem complicated because of the number of steps to be taken, it is really easy to handle encrypted partitions with live-boot. In order to use luks, which is the supported encryption type, you need to install cryptsetup both on the machine you are creating the encrypted partition with and also in the live system you are going to use the encrypted persistent partition with.

To install cryptsetup on your machine:

# apt-get install cryptsetup

To install cryptsetup in your live system, add it to your package-lists:

$ lb config
$ echo "cryptsetup" > config/package-lists/encryption.list.chroot

Once you have your live system with cryptsetup, you basically only need to create a new partition, encrypt it and boot with the persistence and persistence-encryption=luks parameters. We could have already anticipated this step and added the boot parameters following the usual procedure:

$ lb config --bootappend-live "boot=live components persistence persistence-encryption=luks"

Let's go into the details for all of those who are not familiar with encryption. In the following example we are going to use a partition on a usb stick which corresponds to /dev/sdc2. Please be warned that you need to determine which partition is the one you are going to use in your specific case.

The first step is plugging in your usb stick and determine which device it is. The recommended method of listing devices in live-manual is using ls -l /dev/disk/by-id. After that, create a new partition and then, encrypt it with a passphrase as follows:

# cryptsetup --verify-passphrase luksFormat /dev/sdc2

Then open the luks partition in the virtual device mapper. Use any name you like. We use live here as an example:

# cryptsetup luksOpen /dev/sdc2 live

The next step is filling the device with zeros before creating the filesystem:

# dd if=/dev/zero of=/dev/mapper/live

Now, we are ready to create the filesystem. Notice that we are adding the label persistence so that the device is mounted as persistence store at boot time.

# mkfs.ext4 -L persistence /dev/mapper/live

To continue with our setup, we need to mount the device, for example in /mnt.

# mount /dev/mapper/live /mnt

And create the persistence.conf file in the root of the partition. This is, as explained before, strictly necessary. See The persistence.conf file.

# echo "/ union" > /mnt/persistence.conf

Then unmount the mount point:

# umount /mnt

And optionally, although it might be a good way of securing the data we have just added to the partition, we can close the device:

# cryptsetup luksClose live

Let's summarize the process. So far, we have created an encryption capable live system, which can be copied to a usb stick as explained in Copying an ISO hybrid image to a USB stick. We have also created an encrypted partition, which can be located in the same usb stick to carry it around and we have configured the encrypted partition to be used as persistence store. So now, we only need to boot the live system. At boot time, live-boot will prompt us for the passphrase and will mount the encrypted partition to be used for persistence.