Re: Command failed with code -1 (wrong or missing parameters)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

thanks for the info.

On 19/10/2019 11:33, Fourhundred Thecat wrote:
> I ran the same command, this time with --debug. Please see the output
> below. There were no messages in syslog. Also, not sure if it is
> relevant, but the disk I am trying to luksFormat is paravirtualized disk
> in kvm guest (VIRTIO_BLK)

That should work. Anyway, according to the debug log, your system is quite
specific (some notes below), but also it seems to me we have some real bug there.

Could you please try current cryptsetup git version? Or as least released cryptsetup 2.2.1?

If it still fails, it is perhaps better to report it to cryptsetup issues
(copy the same debug log there please) - https://gitlab.com/cryptsetup/cryptsetup/issues
(We will reply there.)

I think we will need much more info and reproducer. Is it some distro kernel, or you 
are compiling it yourself? (There are some kernel features not compiled-in apparently.)

Any more kernel patches applied (looks like grsecurity?)
Can you provide your .config for kernel (to the issue, not to this list please).

> # Checking if cipher aes-xts-plain64 is usable.
> # Userspace crypto wrapper cannot use aes-xts-plain64 (-95).

This is the first problem - why you do not have kernel userspace crypto API enabled?
It should fallback to using dm-crypt temporary devices here, though.

> # Udev is not running. Not using udev synchronisation code.
> # Device-mapper backend running with UDEV support disabled.

Why are not using udev? (Again, it should work but it is quite problematic situation.)

But I do not see the exact fail, apparently the error path is missing some debug info,
so I need to reproduce it first.

Can you try to use LUKS1 (just add --type luks1 to luksFormat) - does it work?

> Existing 'crypto_LUKS' superblock signature on device /dev/vda3 will be
> wiped.
> Existing 'crypto_LUKS' superblock signature on device /dev/vda3 will be
> wiped.

These messages are misleading, it is a failback from an error (wiping header that was
not validated correctly.)

Thanks,
Milan
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
https://www.saout.de/mailman/listinfo/dm-crypt



[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux