暗号化されたLVMボリューム（LUKSデバイス）がブート時にマウントされないのはなぜですか？

このガイドに従って暗号化されたボリュームをセットアップしようとしています

すべてがセットアップされていますが、暗号化されたボリュームのマウントはブート時に次のエラーで失敗します。

fsck.ext4：/ dev / mapper / safe_vaultを開こうとしているときに、そのようなファイルまたはディレクトリが存在しない可能性がありますか？

これは私のセットアップです：

crypttab

$ sudo cat /etc/crypttab
safe_vault  /dev/disk/by-uuid/d266ae14-955e-4ee4-9612-326dd09a463b  none    luks

注意：

uuidから来ています：

$ sudo blkid /dev/mapper/<my_logical_group>-safe_vault 
/dev/mapper/<my_logical_group>-safe_vault: UUID="d266ae14-955e-4ee4-9612-326dd09a463b" TYPE="crypto_LUKS" 

fstab

$ sudo cat /etc/fstab | grep safe_vault
/dev/mapper/safe_vault      /safe-vault     ext4    defaults    0 2

私がやったこと...

だから私はdevoperのウェブサイトに行き、よくある問題のFAQで彼らは言う：

カーネルにデバイスマッパーと暗号化ターゲットがあることを確認してください。「dmsetupターゲット」の出力には、「crypt」ターゲットがリストされます。存在しない場合、またはコマンドが失敗する場合は、デバイスマッパーとcrypt-targetをカーネルに追加します。

だから私はやった、私はcryptターゲットを持っていないことが判明した：

$ sudo dmsetup targets
striped          v1.4.1
linear           v1.1.1
error            v1.0.1

問題は、そのようなターゲットを追加する方法がわからないことです。

これは（cryptターゲットを持っていない）crypttabブート時に設定が無視される可能性があり、暗号化されたボリュームをにマッピングしていないfstabため、エントリをマウントしようとすると失敗する可能性cryptsetupがあり/dev/mapper/safe_vaultます

注意：

暗号化されたボリュームは、手動で正常にマッピング、マウント、および書き込むことができます。

$ sudo cryptsetup luksOpen /dev/mapper/<my_logical_group>-safe_vault safe_vault
Enter passphrase for /dev/mapper/<my_logical_group>-safe_vault: 

$ sudo mount /dev/mapper/safe_vault /safe_vault

これは、マッピングおよびマウント後の外観です。

$ sudo lsblk -o name,uuid,mountpoint
NAME                                  UUID                                   MOUNTPOINT
sda                                                                          
├─sda1                                28920b00-58d3-4941-889f-6249357c56ee   
├─sda2                                                                       
└─sda5                                uhBLE7-Kcfe-RMi6-wrlX-xgVh-JfAc-PiXmBe 
  ├─<my_logical_group>-root (dm-0)       1bed9027-3cf7-4f8d-abdb-28cf448fb426   /
  ├─<my_logical_group>-swap_1 (dm-1)     a40c16c4-7d0c-46d7-afc8-99ab173c20bb   [SWAP]
  ├─<my_logical_group>-home (dm-2)       e458abb7-b263-452d-8670-814fa737f464   /home
  ├─<my_logical_group>-other (dm-3)      0a1eec42-6534-46e1-8eab-793d6f8e1003   /other
  └─<my_logical_group>-safe_vault (dm-4) d266ae14-955e-4ee4-9612-326dd09a463b   
    └─safe_vault (dm-5)               9bbf9f47-8ad8-43d5-9c4c-dca033ba5925   /safe-vault
sr0  

更新

• 私はcryptターゲットを持っていることがわかりましたが、それを表示するdmsetup targetsには最初にcryptsetup luksOpen <my-device>
• UUID@Mikhail Morfikovの答えによると、代わりにs を使用しようとしましたが、ブート時にまだ失敗します。

私はまだ問題は、暗号化されたボリュームがcryptsetup luksOpenブート時にマップされていないため（開いている）、/dev/mapper/<safe_vault or UUID>存在しないため、マウントしようとすると失敗することです（fstab）

更新2

起動時にマウントするのに必要なスクリプトがなかったことがわかりました。@MikhailMorfikovの回答のメモを参照してください。

UUIDに注意する必要があります。たとえば、これは私の構成です：

# lsblk -o name,uuid,mountpoint
├─sda2                         727fa348-8804-4773-ae3d-f3e176d12dac
│ └─sda2_crypt (dm-0)          P1kvJI-5iqv-s9gJ-8V2H-2EEO-q4aK-sx4aDi
│   ├─debian_crypt-swap (dm-1) 3f9f24d7-86d1-4e21-93e9-f3c181d05cf0   [SWAP]
│   ├─debian_crypt-tmp (dm-2)  93fc8219-f985-45fb-bd5c-2c7940a7512d   /tmp
│   ├─debian_crypt-home (dm-3) 12e8566c-8f0f-45ec-8524-6d9d9ee91eae   /home
│   └─debian_crypt-root (dm-4) 9685570b-4c9e-43ea-815e-49d10dc7a1bf   /

4つのボリューム（LVM）を持つ1つの暗号化されたパーティション（sda2）があります。必要なのは、適切なファイルに2つのUUIDを設定することです。sda2 UUIDに移動/etc/crypttabし、ボリュームUUID（たとえば、debian_crypt-root）に移動し/etc/fstabます。

したがって、次のようになります。

# cat /etc/crypttab
sda2_crypt              UUID=727fa348-8804-4773-ae3d-f3e176d12dac   none        luks

# cat /etc/fstab
UUID=9685570b-4c9e-43ea-815e-49d10dc7a1bf       /               ext4    defaults,errors=remount-ro              0 1

/etc/crypttabファイルを変更した後、initramfsを再構築する必要があります。

# update-initramfs -u -k all

注意

パッケージにcryptsetupは、起動時に暗号化ボリュームを自動マウントするためのサポートを提供するスタートアップスクリプトがあるため、インストールする必要があります。

なぜこれを言及するのが面倒ですか？さて、あなたはDebianのWheezyにインストールパッケージは、インストール時にセットアップLVMを場合は、cryptsetupビンを、libcryptsetup4とlvm2ではなくcryptsetup、これは、セットアップLVM＆LUKSデバイスへのツールではなく、ブート時にLUKSデバイスをマウントするために必要なスクリプトを持っています。それらはcryptsetupパッケージに含まれています。

@Mikhail Morfikovの答えは、initramfsステージでのマウントをカバーしているようです。代替手段（ルートファイルシステムでない場合）は、linuzカーネルがロードされた後にsystemdを介してパーティションを自動的に復号化してマウントすることです。もちろん、これはsystemdを実行している場合にのみ可能です。ここで方法を説明します：

/etc/crypttabエントリ：

crypt2 UUID=e412-blahblah /path/to/crypt2.key luks,noauto

以下noautoは、initramfsステージでディスクを復号化しないようにするための指示です。

上記e412-blahblahはluksシステムを含むパーティションのUUIDです。私の場合はパーティション/dev/sdb2です：

# blkid | grep sdb2
/dev/sdb2: UUID="e41274d8-fd83-4632-b560-ad0ba113ae75" TYPE="crypto_LUKS" PARTUUID="5673a908-02"

linuzカーネルの起動時に、systemdは/etc/crypttabファイルを読み取り、ランタイムサービスファイルを作成します/run/systemd/generator/systemd-cryptsetup@crypt2.service。ただし、そのサービスは自動的に実行されません。手動で実行できます

systemctl start systemd-cryptsetup@crypt2.service

ただし、暗号化を解除してから起動時にマウントするには、次のように/etc/fstabする必要があります。

/dev/mapper/crypt2--vg-data /media/crypt-data ext4 defaults,noauto,user,x-systemd.automount,x-systemd.requires=systemd-cryptsetup@crypt2.service 0 2

ここx-systemd.automountに指示されsystemdにマウントするには/media/crypt-data、とx-systemd.requires=systemd-cryptsetup@crypt2.serviceする命令であるにsystemdの復号化はcrypt2それが可能である前に必要とされます。

systemdでは、最初にアクセスされるまでディレクトリは実際にはマウントされません。たとえばls /media/crypt-data、ジャストインタイムでマウントされ、その後に表示され/proc/mountsます。

関連する

「*ルートファイルシステムにキーを持つ暗号化されたデータディスクがあるのはなぜですか？」と尋ねることができます。これは、ルートファイルシステムも暗号化されているため、キーが安全だからです。ルートファイルシステムは、ブートのinitramfsステージで解読されます。これはミハイルの答えです。/etc/crypttabそのためのファイルに別のエントリがあります：

crypt1 UUID=8cda-blahbalh none luks,discard,lvm=crypt1--vg-root

そして、私はそれをセットアップし、ここでブートUSBを説明します