On 9/27/19 5:11 AM, Daniel P. Berrangé wrote:
Some distros are now defaulting to LUKS version 2 which QEMU cannot
process. For our I/O test that validates interoperability between the
kernel/cryptsetup and QEMU, we need to explicitly ask for version 1
of the LUKS format.
Ultimately, it would be nice to get LUKS 2 support in qemu too, but
that's a much bigger job. This is fine for now.
Signed-off-by: Daniel P. Berrangé <berra...@redhat.com>
---
tests/qemu-iotests/149 | 2 +-
tests/qemu-iotests/149.out | 44 +++++++++++++++++++-------------------
2 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/tests/qemu-iotests/149 b/tests/qemu-iotests/149
index 4f363f295f..8ab42e94c6 100755
--- a/tests/qemu-iotests/149
+++ b/tests/qemu-iotests/149
@@ -153,7 +153,7 @@ def cryptsetup_format(config):
(password, slot) = config.first_password()
- args = ["luksFormat"]
+ args = ["luksFormat", "--type", "luks1"]
On Fedora 29, 'cryptsetup --help | grep -A1 type' shows:
-M, --type=STRING Type of device metadata: luks, plain,
loopaes, tcrypt
but that is just 'luks', not 'luks1'.
On CentOS 6 (yeah, I know, not relevenant to qemu any more), --type is
unsupported. But I didn't check our other range of supported systems.
My point, however, is whether this patch needs to be conditionalized
based on what cryptsetup actually supports.
I could not quickly determine if there is some sort of safe no-op
'cryptsetup --type=FOO action /safe/device' that can be used to tell if
--type=FOO is recognized.
Otherwise, this makes sense to me.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
