web-dev-qa-db-ja.com

無効な行/ etc / crypttab

起動しないdebianシステムのトラブルシューティングを行っています。システムは正常に起動し、ある日停止しました（おそらく、apt upgradeに関連しているとは限りません）。小さなブートパーティション（sda1）、sda2上のLUKSコンテナーがあります。 LUKSコンテナ内には、ext4（/および/home）としてフォーマットされた2つのメンバーを持つLVMレイヤーがあります。

起動時にcryptsetupが実行されず、次のエラーが表示されます：「警告：lvmetadへの接続に失敗しました。内部スキャンにフォールバックしています。」次に、コンピューターはinitramfsコンソールにドロップします。

影響を受けたディスクを別のコンピューターにマウントしてchrootすると、initramfsを更新しようとすると、問題ないように見えても/ etc/cryptsetupが無効であることがわかります。エラーは次のとおりです。「cryptsetup：警告：sd1の/ etc/crypttabの行が無効です-」

私のcrypttabファイルには次のものしかありません。

crypt    UUID=<uuid>    none    luks

blkidまたはlsblk適切なUUIDが選択されていることを確認します（/ sda2のUUIDで、子はcryptという名前のLUKSコンテナーです）。

いくつかのバージョン情報：

debian: 9.8
kernel: 4.9.0.6-AMD64
cryptsetup: 1.7.3
lvm: 2.02.168(2)

sd1は別のLUKSデバイスであり、トラブルシューティングのために障害のあるドライブがマウントされているコンピューターのデバイスであることに注意してください。おそらくその場合、警告は単に無視できますか？それでも、障害のあるドライブがブートデバイスとして使用されている場合、update-initramfsの後も問題（暗号化はバイパスされます）が続きます。

この時点では、何が問題なのかよくわからないので、grubを再インストールしてカーネルを再インストールすることを検討しています。ただし、別の手順についての提案をいただければ幸いです。どうもありがとう。

bootluksinitramfscryptsetupcrypttab
2
user001

update-initramfsを実行しようとしたために発生した無効なcrypttabに関するエラーは、ホストコンピュータにもLUKSコンテナがあったことが原因でした。解決策は、他のLUKSデバイスがないシステムからまったく同じ手順を実行することでした（タスクには「ライブ」の起動可能な.isoイメージを使用しました）。 .isoを起動した後、update-initramfs -u -k allは問題なく動作し、システムは起動機能を回復しました。おそらく、レスキューシステムとして使用されるマシンにたまたま存在する無関係なLUKSデバイスを無視するようにcryptsetupに指示できるオプションがあります。

1
user001