我正在使用 Almalinux，以防这与此相关。
我们在本地磁盘上使用 LUKS2，并在其顶部使用 LVM - 因此 /dev/sda1 和 2 未加密，但 /dev/sda3 已加密并用于操作系统。
我们还使用 clevis/tang 进行自动解密（并且运行良好）。
当我们通过 kickstart 构建时，我们会在加密和构建时设置一个临时密码 - 然后当我们完成初始构建时，我们会使用 ansible 根据我们的保险库/安全实践设置高质量的密码。
因此这涉及一个执行下列操作的脚本：
cryptsetup luksOpen -S 0 --test-passphrase /dev/sda3 && cryptsetup luksChangeKey -S0 --force-password --batch-mode
（当然，我们会对‘默认’构建密码进行测试，并将其替换为我们密钥管理系统中的密码）。
最近它开始失败了，我有点困惑不知道可能出了什么问题。
它确实适用于我们最初的“构建”，它使用稍微过时的构建图像，但然后我们dnf update到当前修订版，现在我们似乎无法再使用 luksChangeKey 或 luksAddkey。
# Adding new keyslot 2 by passphrase, volume key provided by passphrase (-1).
# Selected keyslot 2.
# Keyslot 0 priority 1 != 2 (required), skipped.
# Keyslot 1 priority 1 != 2 (required), skipped.
# Trying to open LUKS2 keyslot 0.
# Running keyslot key derivation.
# Reading keyslot area [0x8000].
# Acquiring read lock for device /dev/sda3.
# Opening lock resource file /run/cryptsetup/L_8:3
# Verifying lock handle for /dev/sda3.
# Device /dev/sda3 READ lock taken.
# Reusing open ro fd on device /dev/sda3
# Device /dev/sda3 READ lock released.
# Verifying key from keyslot 0, digest 0.
# Keyslot 2 assigned to digest 0.
# Trying to allocate LUKS2 keyslot 2.
# Found area 548864 -> 806912
# Running argon2id() benchmark.
# PBKDF benchmark: memory cost = 65536, iterations = 4, threads = 4 (took 72 ms)
# PBKDF benchmark: memory cost = 227555, iterations = 4, threads = 4 (took 264 ms)
# PBKDF benchmark: memory cost = 1048576, iterations = 6, threads = 4 (took 1982 ms)
# Benchmark returns argon2id() 6 iterations, 1048576 memory, 4 threads (for 512-bits key).
# JSON does not fit in the designated area.
# Not enough space in header json area for new keyslot.
# Rolling back in-memory LUKS2 json metadata.
# Releasing crypt device /dev/sda3 context.
# Releasing device-mapper backend.
# Closing read only fd for /dev/sda3.
Command failed with code -1 (wrong or missing parameters).
我想知道是否有人能够帮助我了解这里出了什么问题，以及我需要做什么来解决它。
是否有一个“初始标头大小”选项可以指定在我们的构建中？或者 cryptsetup 的参数？或者我“只是”发现了一个错误？（但我不相信像这种广泛使用的东西cryptsetup会有“没有人可以更改密码”之类的错误）
这是 LUKs 标头在示例主机上的样子。
LUKS header information
Version: 2
Epoch: 5
Metadata area: 16384 [bytes]
Keyslots area: 16744448 [bytes]
UUID:
Label: (no label)
Subsystem: (no subsystem)
Flags: (no flags)
Data segments:
0: crypt
offset: 16777216 [bytes]
length: (whole device)
cipher: aes-xts-plain64
sector: 512 [bytes]
Keyslots:
0: luks2
Key: 512 bits
Priority: normal
Cipher: aes-xts-plain64
Cipher key: 512 bits
PBKDF: argon2id
Time cost: 9
Memory: 1048576
Threads: 4
Salt:
AF stripes: 4000
AF hash: sha256
Area offset:32768 [bytes]
Area length:258048 [bytes]
Digest ID: 0
1: luks2
Key: 512 bits
Priority: normal
Cipher: aes-xts-plain64
Cipher key: 512 bits
PBKDF: pbkdf2
Hash: sha256
Iterations: 1000
Salt:
AF stripes: 4000
AF hash: sha256
Area offset:290816 [bytes]
Area length:258048 [bytes]
Digest ID: 0
Tokens:
0: clevis
Keyslot: 1
Digests:
0: pbkdf2
Hash: sha256
Iterations: 105025
Salt:
Digest:
我是不是错过了什么深刻的东西？正如所说，如果我不将盒子“升级”到较新的内核，我确信这可以工作，所以我当前的解决方法是构建它，手动重新键入它，然后继续更新它，但这似乎……不是最理想的。
cryptsetup 版本 2.6.0 和 2.7.2
head -c 1M /dev/sda3 | strings -n 128
重新格式化：
{
"keyslots": {
"0": {
"type": "luks2",
"key_size": 64,
"af": {
"type": "luks1",
"stripes": 4000,
"hash": "sha256"
},
"area": {
"type": "raw",
"offset": "32768",
"size": "258048",
"encryption": "aes-xts-plain64",
"key_size": 64
},
"kdf": {
"type": "argon2id",
"time": 7,
"memory": 1048576,
"cpus": 4,
"salt": "(removed)"
}
},
"1": {
"type": "luks2",
"key_size": 64,
"af": {
"type": "luks1",
"stripes": 4000,
"hash": "sha256"
},
"area": {
"type": "raw",
"offset": "290816",
"size": "258048",
"encryption": "aes-xts-plain64",
"key_size": 64
},
"kdf": {
"type": "pbkdf2",
"hash": "sha256",
"iterations": 1000,
"salt": "(removed)"
}
}
},
"tokens": {
"0": {
"type": "clevis",
"keyslots": [
"1"
],
"jwe": {
"ciphertext": "(removed)",
"encrypted_key": "",
"iv": "(removed)",
"protected": "",
"tag": "(removed)"
}
}
},
"segments": {
"0": {
"type": "crypt",
"offset": "16777216",
"size": "dynamic",
"iv_tweak": "0",
"encryption": "aes-xts-plain64",
"sector_size": 512
}
},
"digests": {
"0": {
"type": "pbkdf2",
"keyslots": [
"0",
"1"
],
"segments": [
"0"
],
"hash": "sha256",
"iterations": 88086,
"salt": "(removed)",
"digest": "(removed)"
}
},
"config": {
"json_size": "12288",
"keyslots_size": "16744448"
}
}
编辑2：情节变得更加复杂：luksHeaderBackup 然后恢复失败。
但删除“插槽 0”并添加密钥仍然有效。（假设您可以提取“插槽 1”，但在我的案例中clevis-luks-pass效果已经足够好了）
