Debian Jessie の systemd で暗号化されたマルチディスクルートファイルシステムを確実に起動する際には、多くの問題があります。同時にパスワードを一度入力するだけです。以前は、Debianはdecrypt_derived最初のデバイスを除くすべてのデバイスに対して/ etc / crypttabのキースクリプトを使用してこの問題を処理しましたが、これはうまくいきました。
しかし、systemdが導入された場合、正しく動作しません。systemd-cryptsetup-generatorキーボードスクリプトを処理せず、この問題を解決する方法に関する追加情報を見つけようとしたときに、いくつかのカスタマイズへのあいまいな参照のみが見つかりました。パスワードプロキシ中Eメール役に立たないアドバイスだけを提供したシステム開発者の言葉：「エージェントをさらに書くのは簡単です。従う基本的なアルゴリズムは次のとおりです。」次に、取るべき13のステップをリストします。明らかにエンドユーザーには適していません。
/etc/crypttabDebian では、systemd に、ブート中にそれを無視するか完全に無視するように指示するいくつかのカーネルオプションを使用してある程度動作させるようにしました。 Debianはupdate-initramfsコアスクリプトをinitramfsにコピーし、systemdが引き継ぐ前にデバイスのロックを解除しますが、systemdにはデバイスを復号化するためのユニットファイルがないため、後で問題が発生することがわかりました。だから時々これに依存するマウントがあります。起動が止まったり遅れたりするようです。これが問題になる1つの場所は、btrfsサブボリュームをマウントしようとするときです。サブボリュームはルートと同じ物理デバイスからマウントされますが、systemdはデバイスがロック解除され、起動時に停止することを知りません。
TL;DR - 実際の質問:
パスワードを一度入力するだけの複数のデバイス（btrfsシステム、LVMイメージなど）で暗号化されたルートファイルシステムをsystemdはどのように処理しますか？私はこれが非常に珍しい状況だとは思わない。したがって、これを行う方法があることを願っています。
私はいくつかの可能な解決策を考えてみました。
- キーファイルを含む小さな暗号化パーティションで、ルートの前にロック解除されます。ルート化されたデバイスはこのキーファイルを参照します。これをsystemdにどのように伝えることができますか？
- パスワードを記憶し、起動時にそれを必要なすべてのデバイスに渡すinitramfsで実行される一種のキャッシュパスワードエージェント。
- 誰かがdecryption_derivationをシミュレートするsystemdエージェントを作成しました。これを私のランチャーにどのように統合しますか？
私はDebianだけを実行していますが、問題の解決策を見つけるために数日間努力した後、これがシステム全体の問題である可能性があると感じました。
ベストアンサー1
これはよく知られた問題であり、現時点では解決策はありません。
Debian（および他のシステム）では、systemdは並列プロセスとさまざまなテストのために暗号化されたBTRFS配列を組み立てることができません。 （正しく）マウントするには、BTRFS配列のすべてのボリュームが存在する必要がありますが、BTRFS配列のすべてのボリュームは設計上同じUUIDを持つため、systemdは他のボリュームを待たずに最初に開いたボリュームをマウントしようとします。同じUUIDが原因でシステムがさらに混乱しました.)
現在Debianで暗号化されたBTRFSボリュームを使用する唯一の方法は次のとおりです。いいえsystemd（パッケージなど）を使用sysvinit-coreしてくださいsystemd-shim。 「システム化された方法」は不可能です。