`cryptsetup luksOpen <device> <name>` fails to set up the specified name mapping

HardenedArray has a helpful archlinux-installation guide at [Efficient Encrypted UEFI-Booting Arch Installation](https://gist.github.com/HardenedArray/31915e3d73a4ae45adc0efa9ba458b07) . However, I encountered difficulty early in the installation process -- specifically, at the point of opening my LUKS partition. The command cryptsetup -c aes-xts-plain64 -h sha512 -s 512 --use-random luksFormat /dev/sda3 completes without error, but after I enter the command cryptsetup luksOpen /dev/sda3 tsundoku, _/dev/mapper/tsundoku_ does not become available. ls /dev/mapper lists _/dev/mapper/control_ alone, and not also _/dev/mapper/tsundoku_ as I would expect. The following error message appears upon cryptsetup luksOpen /dev/sda3 tsundoku --verbose --debug: "Trying to read ... LUKS2 header at offset .... LUKS header read failed (-22). Command failed with code -1 (wrong or missing parameters)." Could anyone offer any hints at to the cause of this error? My attempts at online research to this point haven't been fruitful. Thanks much --- EDIT --- I've asked this question for help to achieve any of three goals: (1) to install arch-linux (in any manner) on a 6ish-year-old x86-64 Intel Core i5 2.50GHz ASUS; (2) more specifically, to install arch-linux securely with an encrypted partition; (3) to learn why, despite my expectations, cryptsetup luksOpen /dev/sda3 tsundoku does not create a _tsundoku_ mapping entry in the path _/dev/mapper_. I'm a newcomer to arch-linux, so although I'd prefer installing the OS with encryption, I'd settle for installing it in any way. I haven't had much luck following the installation instructions in the official arch wiki in the past, so upon seeing HardenedArray's clearly delineated installation guide, I thought I'd give it a go -- worst case scenario being that I might encounter a problem like the one described above, whereby I might learn something new. As for the issue, here are some more details: As per HardenedArray's guide: I gdisk /dev/sda and create the following partitions: * /dev/sda1, default, 100M, EF00 * /dev/sda2, default, 250M, 8300 * /dev/sda3, default, default, 8300 Then I do the following: mkfs.vfat -F 32 /dev/sda1 mkfs.ext2 /dev/sda2 At this point, I attempt to initialize a LUKS partition and set up a mapping. > 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 ----- Are the steps I've listed above inaccurate in any way? Perhaps there were alternatives I should have taken instead or intervening actions that I missed? If not, is the command cryptsetup luksOpen /dev/sd{a} {volume} supposed to create a volume mapping in the path _/dev/mapper_? If so, do the details I've added above allow anyone to ascertain why the path _/dev/sda3/tsundoku_ does not appear on my machine? And if not, is there any additional information that I could add to make the problem clearer? Thanks much.