systemd cryptsetupがすでにマウントされているルートパーティションを再マウントしようとするのはなぜですか?

systemd cryptsetupがすでにマウントされているルートパーティションを再マウントしようとするのはなぜですか?

私の/etc/crypttabは次のようになります。

sda7_crypt UUID=<...> /dev/sda8:/keyfile luks,discard,keyscript=/lib/esi/tpm_key_pass

sda7_crypt私はルートファイルシステムなので、update-initramfs最初にそれを使用してパスワードを復号化します(それ以外の場合は起動を続行できません)。

ただし、systemd はsystemd-cryptsetup@sda7_crypt.servicea に依存するユニットを自動的に生成し、dev-sda8:-keyfile.deviceそのユニットはタイムアウトします。これは最終的に失敗しますが、開始時間が遅くなり、エラーメッセージが生成されます。

initramによってすでにマウントされており、systemdによってマウントする必要がないことを示す方法は何ですか?noautocrypttabでオプションを検討しましたが、これがiniトラムにロードされない可能性があることを心配していますか?

修正する:

試してみましたがnoauto成功しませんでした。まだinitramにインストールされていますが、まだ起動しようとしています。 crypttab は次のようになります。

sda7_crypt UUID=<...> /dev/sda8:/keyfile luks,discard,keyscript=/lib/esi/tpm_key_pass,noauto

これをきれいにするにはどうすればよいですか?

答え1

Debian のバグレポートによると、systemd デバイスを無効にすることが現在最善の解決策です。

systemctl mask systemd-cryptsetup@root_crypt.service

このアイデアを思い出したミシェルに感謝!

答え2

これは、systemdとそれが正確にどのように機能するかに関する2つの別々の問題であることがわかりましたsystemd-cryptsetup-generator

  1. オプションが認識されないため、keyscript=...次の有効なキーをブロックします。passdev/dev/sda8:/keyfile
  2. 自動的に作成されたsystemdデバイスは、プロジェクトがインストールされたことをsystemd-cryptsetup-generator認識するほどスマートではなく、再インストールを試みます。

詳細については、この Debian バグレポートをご覧ください。https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618862

バグレポートによれば、カーネルオプションを渡してシステム単位の生成を防ぐことができますが、これは防止luks=noされます。みんなcrypttabが自動的にマウントされます。暗号化されたルートのみが問題ありませんが、別のパーティションがある場合はマウントされません。

関連情報