Provided by: open-infrastructure-system-boot_20190301-lts1-3_all
名前
persistence.conf - live-boot 状態保持用メディアの設定ファイル
説明
live-boot が「persistence」というラベル (GPT の名前やファイル名も含みますがここからは「ラ ベル」と呼びます) を付けられた保持用ボリュームを調査するとき、そのボリュームの保持方法はそ のファイルシステムの最上部に置かれた persistence.conf ファイルにより全面的に独自化できま す。こういったラベルを付けられたボリュームにはそういったファイルがないといけません。ない場 合は無視します。 persistence.conf の形式では空行や「#」で始まる行 (コメント用) を両方とも利用でき、そういっ た行は解釈されず無視されます。いわゆる「独自マウント」は ディレクトリ [オプション]... の形式で、大まかに言い換えると「オプション一覧により指示した方法でディレクトリを保持す る」ということになります。 独自マウントそれぞれについてディレクトリには絶対パスを使う必要があり、空白文字や特別なパス である「.」や「..」を含めること、/live (やそのサブディレクトリ) を使うことはできませ ん。Live ファイルシステムのディレクトリに対するあらゆる変更 (ファイルの削除や作成、変更) はそれを有効にした段階でソースディレクトリと呼ばれる保持用メディアのディレクトリに相当する パスに持続的に保管されます。保持を実現するデフォルトの方法は対応するソースディレクトリを ディレクトリに対して単純にバインドマウントする方法ですが、これはオプションを使うことで変更 できます。 独自マウントは全て順番に行われるため、2つの独自マウントで互いに「隠す」ようなことはできま せん。例えば2つのディレクトリ /a と /a/b があるとすると、この場合は常にまず /a がマウント され、それから /a/b がマウントされます。これは persistence.conf の他の行の順を問わず成り立 ち、異なる保持用メディアにある複数の persistence.conf ファイルを同時に使う場合でも同様で す。しかし、独自マウントではソースディレクトリを別の独自マウントのソースディレクトリ内にす ることは禁止されているため、live-boot により自動生成されたソースディレクトリは同一のメディ アでの /a と /a/b のような「入り組んだ」マウントをサポートしません。この場合は source オプ ション (以下参照) を使い、対象ディレクトリが必ず異なるソースディレクトリにあるようにしない といけません。 特定の独自マウントのソースディレクトリが保持用メディアに存在しない場合は自動的に作成さ れ、そのディレクトリにふさわしい権限と所有がセットされます。ディレクトリの内容を保持用メ ディアのソースディレクトリにコピーすることでもこの自動処理は行われます。link や union オプ ション (以下参照) を使った場合はこの自動処理は行われません。
オプション
persistence.conf で定義する独自マウントでは以下のオプションをコンマで区切った一覧の形で受 け付けます: source=パス 指定した場合は保持用メディアのパスに保持内容の変更を保管します。パスは (その保持用メ ディアのルートからの) 相対パスを使う必要があり、空白文字や特別なパスである「.」や 「..」については、「.」だけが単体で使われたときにはその保持用メディアのルートを指しま すが、その例外を除いて含めることができません。このオプションが関連するのはほとんど が、これ以外ではエラーを引き起こす入り組んだ独自マウントにしたい場合、またはメディア全 体のルートを利用できるようにしたい場合です (現在では非推奨となっている home-rw という 種類の保持に似ています)。 以下のオプションは相互に排他です (効果があるのは最後に指定したものだけです): bind ソースディレクトリをディレクトリにバインドマウントします。これはデフォルトです。 link ソースディレクトリのディレクトリ構造を保持用メディアのディレクトリに作成し、ディレクト リの対応する位置からソースディレクトリの各ファイルに向けてシンボリックリンクを作成しま す。リンクと同一名の既存のファイルやディレクトリは全て上書きされます。ディレクトリ内に あるリンクの削除はリンクを削除するだけで、ソースの対応するファイルは削除しないことに注 意してください。削除したリンクは再起動後には再び現れます。ファイルを恒久的に追加、削除 するにはソースディレクトリで直接その作業を行わないといけません。 事実上、link は既にソースディレクトリにあるファイルだけを保持し、ディレクトリにあるそ れ以外のファイルは保持しません。保持するファイルをこのオプションの対象とするには手作業 によりソースディレクトリに追加する必要があり、そうすることでディレクトリに、既にそこに あるファイルに加えて現れるようになります。このオプションは特定のファイルだけを保持する 必要があり、それがあるディレクトリ全体が必要ではない場合、例えばユーザのホームディレク トリにある設定ファイルの一部を保持する場合に有用です。 union 結合ファイルシステムの rw ブランチを保持用メディアに保存するため、変更点だけを持続的に 保管します。バインドマウントと比較するとこの方法は潜在的にディスク使用量を減らせる可能 性があり、また読み取り専用メディアに追加したファイルを隠しません。1つ注意があり、結合 後に実際のファイルシステムのルートではなくイメージの読み取り専用ファイルシステムから ディレクトリを使うため、(例えば live-config により) ブート後に作成されたファイルは結合 後には見えなくなります。このオプションは live-boot の union ブートパラメータにより指定 された結合ファイルシステムを使います。
ディレクトリ
/live/persistence 保持用ボリュームは全てここで (デバイス名に対応するディレクトリで) マウントされま す。persistence.conf ファイルはこのマウントや任意のソースディレクトリから (link オプ ションを使った独自マウントではこちらが特に実用的) 簡単に編集できます。
例
保持用ボリューム VOL があり、その persistence.conf ファイルに以下の4行を収録しているものと しましょう (番号は参照しやすいように付加しています): 1. /home/user1 link,source=config-files/user1 2. /home/user2 link,source=config-files/user2 3. /home 4. /usr union それぞれに対応するディレクトリ: 1. VOL/config-files/user1 (ただし source オプションを指定しない場合は VOL/home/user1) 2. VOL/config-files/user2 (ただし source オプションを指定しない場合は VOL/home/user2) 3. VOL/home 4. VOL/usr 1と2の例では source オプションをセットする必要があります。そうしないと3のソースと入り組ん でしまい不正となるためです。 1行目と2行目の独自マウントが3行目によって隠されるのを回避するため3行目は1行目と2行目よりも 先に処理されます。3行目が処理された時点で VOL/home は単純に /home に対してバインドマウント した状態になります。1行目と2行目で起きたことを説明するため、以下のファイルが存在するとしま しょう: a. VOL/config-files/user1/.emacs b. VOL/config-files/user2/.bashrc c. VOL/config-files/user2/.ssh/config それにより作成されるリンクやディレクトリ: リンク: /home/user1/.emacs -> VOL/config-files/user1/.emacs (a の場合) リンク: /home/user2/.bashrc -> VOL/config-files/user2/.bashrc (b の場合) ディレクトリ: /homea/user2/.ssh (c の場合) リンク: /home/user2/.ssh/config -> VOL/config-files/user2/.ssh/config (c の場合) 別の主張があるかもしれませんが、上記の persistence.conf ファイルの例では3行目が既に /home の全てを保持対象としているため1行目と2行目は不要です。link オプションはディレクトリ全体を 保持したいのではなく、そのディレクトリ中やサブディレクトリにある特定のファイルを保持したい という状況を対象としています。 4行目はそのディレクトリ (とソースディレクトリ) が他のどの独自マウントとも完全に分離してい るためいつでもマウントできます。マウントすると、VOL/usr は union オプションが指定されてい るため rw ブランチになり、元の読み取り専用ファイルシステムと比較した差分だけが収録されま す。そのため、バインドマウントと比較すると容量の面で非常に効率良くパッケージを /usr にイン ストールできます。これは後者では初期の自動処理で /usr 全体を VOL/usr にコピーする必要があ るためです。
関連項目
live-boot(7) live-build(7) live-config(7) live-tools(7)
ホームページ
live-boot 及び Live システムプロジェクトについてのさらなる情報 は、<http://live-systems.org/> のホームページや <http://live-systems.org/manual/> のマニュ アルにあります。
バグ
バグは <http://bugs.debian.org/> にあるバグ追跡システムに live-boot パッケージのバグ報告と して提出するか、<debian-live@lists.debian.org> にある Live システムのメーリングリスト宛て にメールを書くことにより報告できます。
作者
live-boot は Daniel Baumann さん <mail@daniel-baumann.ch> により書かれました。