web-dev-qa-db-ja.com

暗号化された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

私がやったこと...

だから私は開発者のウェブサイトに行きました 一般的な問題FAQ で彼らは言う：

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

そのため、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>を実行する必要がありました
  • @Mikhail Morfikovの answer によると、代わりにUUIDsを使用してみましたが、それでも起動時に失敗します。

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

更新2

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

lvmcryptsetup
15
pgpb.padilla

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パッケージは、起動時に暗号化されたボリュームの自動マウントをサポートする起動スクリプトを備えているため、インストールする必要があります。

なぜこれについて言及するのが面倒なのですか？まあ、インストール中にLVMをセットアップした場合、Debian Wheezyはパッケージ cryptsetup-bin 、libcryptsetup4とlvm2をインストールしますが、cryptsetupはインストールしないため、次のツールがあります。 LVMおよびLUKSデバイスをセットアップしますが、起動時にLUKSデバイスをマウントするために必要なスクリプトはセットアップしません。これらはパッケージ cryptsetup に含まれています。

16
Mikhail Morfikov

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

/etc/crypttabエントリ：

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

ここでnoautoはnotinitramfsステージ中にディスクの復号化を試みる命令です。

上記の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/[email protected]を作成します。ただし、そのサービスは自動的には実行されません。手動で実行できます

systemctl start [email protected]

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

/dev/mapper/crypt2--vg-data /media/crypt-data ext4 defaults,noauto,user,x-systemd.automount,[email protected] 0 2

ここで、x-systemd.automountはsystemdへの命令であり、/media/crypt-dataをマウントします。また、[email protected]はsystemdへの命令であり、crypt2が可能になる前に必要です。

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

関連

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

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

そして私はそれとブートUSBの設定について説明します ここ

0
Craig Hicks