On Fri, Sep 27, 2019 at 10:26:27AM -0500, Eric Blake wrote: > 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 tested RHEL-7 and it supported "luks1" despit the docs not reflecting it. The docs fix seems to be quite recent. That said, I noticed that RHEL-7 (surprisingly) has support for LUKSv2, so might not have been a good test platform. I'll check what Debian/Ubuntu support in this respect. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|