进行搜索后，发现其他人似乎因为密码设置而遇到了更复杂的问题，但我的问题是做一些简单的事情时遇到的。
使用全新安装的 Lubuntu 18.10 32 位（内核已更新），我可以这样创建加密分区：
cryptsetup --verbose --verify-passphrase luksFormat /dev/mmcblk0
WARNING: Device /dev/mmcblk0 already contains a 'crypto_LUKS' superblock signature.
WARNING!
========
This will overwrite data on /dev/mmcblk0 irrevocably.
Are you sure? (Type uppercase yes): YES
Enter passphrase for /dev/mmcblk0:
Verify passphrase:
Existing 'crypto_LUKS' superblock signature on device /dev/mmcblk0 will be wiped.
Key slot 0 created.
Command successful.
如果给出的密码是字母a，则我无法解锁：
cryptsetup --verbose luksOpen /dev/mmcblk0 crypt
Enter passphrase for /dev/mmcblk0:
No key available with this passphrase.
Enter passphrase for /dev/mmcblk0:
（我也尝试了 zulucrypt，结果相同）
由于我使用安装程序的加密功能安装了 Lubuntu，因此我可以比较我的系统原生使用的内容和cryptsetup我的 mmc 驱动器上制作的内容。
cryptsetup luksDump /dev/sda1
相关部分似乎是：
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha256
Payload offset: 4096
MK bits: 512
我看到的两个转储之间的唯一区别是，对于我的本地驱动器，底部的“MK 位”是 512，但对于 mmc，它是 256。
我不知道这是否相关，但我还看到我的本地驱动器有两个密钥插槽，而 mmc 只有一个。（我的本地驱动器有两个密钥插槽，这让我希望/想知道安装程序是否会放入一个重复的密钥，以防第一个密钥损坏。）
一位评论者要求我尝试通过以下方式提供密码：
echo -n 'a' | cryptsetup --verbose luksOpen /dev/mmcblk0 crypt
Can't do passphrase verification on non-tty inputs.
No key available with this passphrase.
Command failed with code -2 (no permission or bad passphrase).
提供密码的另一种方法：
echo 'a' > interactive_pass
cat interactive_pass | cryptsetup luksAddKey /dev/mmcblk0
No key available with this passphrase.
使用密钥文件。
我无法理解这一点。我摸索了一段时间，但还是停了下来，因为我分不清是使用错误还是它本身有问题。
zulucrypt 有一种方法可以创建密钥文件，但它只是说Failed To Generate Key。它很简单，所以我确定我使用得正确（以 root 身份运行，对我想要创建的文件具有写入权限）
答案1
TL;DR - 检查媒体是否可靠；luksFormat否则，luksOpen不可靠。
至少可以从以下几个方面来思考这个问题：
- 提供的密码错误
- 密码输入错误
- 基本软件（如 cryptsetup 本身）存在问题。
出于好奇，我决定对 mmc 驱动器进行完整格式化（“从头开始”），但检查：
sudo mkfs.ext4 /dev/mmcblk0 -cc
mke2fs 1.44.4 (18-Aug-2018)
/dev/mmcblk0 contains a ext4 file system
last mounted on Tue Mar 5 11:30:02 2019
Proceed anyway? (y,N) y
Discarding device blocks: done
Creating filesystem with 15591936 4k blocks and 3899392 inodes
Filesystem UUID: 0ab72f40-d2a2-408d-b4ca-d5e8fcc27ec7
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424
Testing with pattern 0xaa: done
Reading and comparing: done
Testing with pattern 0x55: done rs)
Reading and comparing: done rs)
Testing with pattern 0xff: done rs)
Reading and comparing: done rs)
Testing with pattern 0x00: done rs)
Reading and comparing: done rs)
Block 0 in primary superblock/group descriptor area bad.
Blocks 0 through 9 must be good in order to build a filesystem.
Aborting....
我已经知道这是怎么回事了……
由于我以前从未进行过这样的格式化，因此我格式化了第二个存储设备（USB 棒），并进行了检查，格式化成功。按照相同的过程cryptsetup格式化并打开该 USB 棒工作。这揭示了正在发生的另一个问题：
- 密码正在已收到以错误的方式
我怀疑luksFormat没有进行任何健全性检查来确保其数据确实可以读取。
作为后续，我已经在 Windows 下进行了非快速格式化，并且运行良好。我还进行了完整的写入-读取-比较测试，也成功了。出于好奇，我还有其他测试要执行，但这很可能（不知何故）是 Linux 特有的问题。我不会深入研究这个问题，但我的结论是，在出现问题的特定平台上进行所有格式化和测试非常重要。