`cryptsetupluksOpen `指定された名前マップを設定できません。

HardenedArrayには便利なArchlinuxインストールガイドがあります。効率的な暗号化UEFIブートアーキテクチャのインストール。

しかし、インストールプロセスの早い段階で、特にLUKSパーティションを開くときに問題が発生しました。

コマンドはcryptsetup -c aes-xts-plain64 -h sha512 -s 512 --use-random luksFormat /dev/sda3エラーなしで完了しますが、コマンドを入力したcryptsetup luksOpen /dev/sda3 tsundoku後/dev/mapper/tsudokuない。

ls /dev/mapperリスト/dev/マッパー/制御同時にではなく、一人で/dev/mapper/tsudoku私が期待したように。

次のエラーメッセージが表示されますcryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug。

「オフセットからLUKS2ヘッダーを読み取ろうとしています.... LUKSヘッダーの読み取りに失敗しました（-22）

誰でもこのエラーの原因に関するヒントを提供できますか？これまでのオンライン調査のための私の試みは欠実していませんでした。

非常にありがとう

- - 編集する - -

私は3つの目標の1つに役立つようにこの質問をします。 （1）6年のx86-64 Intel Core i5 2.50 GHz ASUSに（何らかの方法で）Arch-Linuxをインストールします。 （2）より具体的には、Arch-Linuxをインストールします。 (3) 私の期待にもかかわらず、これがcryptsetup luksOpen /dev/sda3 tsundoku生成されなかった理由を理解する。ジュンデパスの項目マッピング/dev/マッパー。

私はアーチLinuxに初めて触れたので、暗号化を使ってOSをインストールすることを好みますが、何らかの方法でインストールすることを選択します。

以前は公式アーチウィキのインストールガイドラインに従わなかったので、HardenedArrayの明確に説明されたインストールガイドを見てから試してみたいと思いました。最悪の場合、次の問題が発生する可能性があります。上記のように、そうすれば新しいことを学ぶことができます。

質問の詳細は次のとおりです。

HardenedArrayのガイドに従って、gdisk /dev/sda次のパーティションを作成します。

• /dev/sda1、デフォルト、100M、EF00
• /dev/sda2、デフォルト、250M、8300
• /dev/sda3、デフォルト、デフォルト、8300

次に、次の操作を行います。

mkfs.vfat -F 32 /dev/sda1

mkfs.ext2 /dev/sda2

この時点で、LUKSパーティションを初期化してマッピングを設定しましょう。

> cryptsetup --verbose -c aes-xts-plain64 -h sha512 -s 512 --use-random luksFormat /dev/sda3

Command successful

> cryptsetup -v isLuks /dev/sda3

Command successful

> ls /dev/mapper

control

> cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug

    cryptsetup 2.0.0. processing "cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug"
    Running command open.
    Locking memory.
    ...
    Trying to load any crypt type from device /dev/sda3.
    Crypto backend ... initialized ...
    Detected kernel Linux 4.14.9-1-ARCH x86_64.
    ...
    Reading LUKS header of size 1024 from device /dev/sda3.
    ...
    Activating volume tsundoku using token -1.
    STDIN descriptor passphrase entry requested.
    Activating volume tsundoku [keyslot -1] using passphrase.
    ...
    Detected dm-ioctl version 4.37.0.
    Device-mapper backend running with UDEV support enabled.
    dm status tsundoku [ opencount flush ] [...] (...)
    Trying to open key slot 0 [ACTIVE_LAST].
    Reading key slot 0 area.
    Using userspace crypto wrapper to access keyslot area.
    Trying to open key slot 1 [INACTIVE].
    # key slots 2-7 are also [INACTIVE]
    Releasing crypt device /dev/sda3 context.
    Releasing device-mapper backend.
    Unlocking memory.
    Command failed with code -2 (no permission or bad passphrase).

> ls /dev/mapper

control

> cryptsetup luksDump /dev/sda3

    LUKS header information for /dev/sda3
    Version: 1
    Cipher name: aes
    Cipher mode: xts-plain64
    Hash spec: sha512
    ...
    UUID: 56d8...
    Key Slot 0: ENABLED
    ...
    Key Slot 1: DISABLED
    # Key Slots 2-7 are also DISABLED

上記の手順に不正確な内容がありますか？たぶん別の選択肢を選ぶべきですか？それとも仲裁が欠けているのでしょうか？

それ以外の場合、yesコマンドはcryptsetup luksOpen /dev/sd{a} {volume}パスにボリュームマップを作成する必要があります。/dev/マッパー？

もしそうなら、あなたが上に追加した詳細から誰もがルートが変更された理由を知ることができますか？/dev/sda3/tsudoku私のコンピュータに表示されませんか？そうでない場合は、質問をより明確にするために追加できる他の情報がありますか？

とても感謝しています。