Corey, please could you always attach the command output with additional --debug switch? It helps to debug the issue, maybe the reason will be apparent there. Thanks.
I do not see any reason it shoulld fail here though.

Sure. I wasn't aware of that flag until now.


[root@mckinley-01 ~]# echo Str0ngP455w0rd### | cryptsetup --debug  luksFormat --type luks2 /dev/test/lv 
# cryptsetup 2.0.3 processing "cryptsetup --debug luksFormat --type luks2 /dev/test/lv"
# Running command luksFormat.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /dev/test/lv.
# Trying to open and read device /dev/test/lv with direct-io.
# Initialising device-mapper backend library.
# STDIN descriptor passphrase entry requested.
# Checking new password using default pwquality settings.
# New password libpwquality score is 100.
# PBKDF argon2i, hash sha256, time_ms 2000 (iterations 0), max_memory_kb 1048576, parallel_threads 4.
# Formatting device /dev/test/lv as type LUKS2.
# Crypto backend (gcrypt 1.5.3) initialized in cryptsetup library version 2.0.3.
# Detected kernel Linux 3.10.0-931.el7.x86_64 x86_64.
# Topology: IO (8192/33553920), offset = 512; Required alignment is 1048576 bytes.
# Checking if cipher aes-xts-plain64 is usable.
# Using userspace crypto wrapper to access keyslot area.
# Creating new digest 0 (pbkdf2).
# Setting PBKDF2 type key digest 0.
# Running pbkdf2(sha256) benchmark.
# PBKDF benchmark: memory cost = 0, iterations = 91275, threads = 0 (took 359 ms)
# PBKDF benchmark: memory cost = 0, iterations = 110890, threads = 0 (took 591 ms)
# Benchmark returns pbkdf2(sha256) 110890 iterations, 0 memory, 0 threads (for 256-bits key).
# Digest JSON:
# {
  "type":"pbkdf2",
  "keyslots":[
  ],
  "segments":[
  ],
  "hash":"sha256",
  "iterations":13861,
  "salt":"h2eH4327A78Vm\/qaR1Nc0lNDQ37xVdKb3CzgfOnOZ0M=",
  "digest":"8GpNnwlUBMilVJ2v\/Nt9xHJ5wcpjOzdeIVoqwk3oUnw="
}
# Segment 0 assigned to digest 0.
# Header JSON:
# {
  "keyslots":{
  },
  "tokens":{
  },
  "segments":{
    "0":{
      "type":"crypt",
      "offset":"4194305",
      "iv_tweak":"0",
      "size":"dynamic",
      "encryption":"aes-xts-plain64",
      "sector_size":512
    }
  },
  "digests":{
    "0":{
      "type":"pbkdf2",
      "keyslots":[
      ],
      "segments":[
        "0"
      ],
      "hash":"sha256",
      "iterations":13861,
      "salt":"h2eH4327A78Vm\/qaR1Nc0lNDQ37xVdKb3CzgfOnOZ0M=",
      "digest":"8GpNnwlUBMilVJ2v\/Nt9xHJ5wcpjOzdeIVoqwk3oUnw="
    }
  },
  "config":{
    "json_size":"12288",
    "keyslots_size":"4161536"
  }
}
# Offset field has to be aligned to sector size: 512
Cannot format device /dev/test/lv.
# Releasing crypt device /dev/test/lv context.
# Releasing device-mapper backend.
# Unlocking memory.
Command failed with code -1 (wrong or missing parameters).

Ok, so it fails LUKS2 parameters validation because we ended with crypt segment not aligned to sector size, strange. That should never happen, even bogus values should be rounded properly...

What is the IO topology info for that multipath device? (lsblk- t)

Created attachment 1474453 [details]
verbose format and lsblk output

There's a bug in luks2 align offset calculation. Thanks Corey!

Moving to 7.7 It's a bug in luks2 format only which is not default in RHEL7.

Fix upstream by:

- https://gitlab.com/cryptsetup/cryptsetup/commit/dd36d56d472e1ea1db74d64d2e6a8d8ece2e7a76

To reproduce it easily without complex device setup:

1) modprobe scsi_debug dev_size_mb=25 sector_size=512 physblk_exp=3 lowest_aligned=1
2) cryptsetup luksFormat --type luks2 /dev/sdx (<- scsi debug disk)

(note to myself) In follow-up to the fix, it would be wise to backport also following commits, because LUKS2 was too restrictive about data alignment values:

- https://gitlab.com/cryptsetup/cryptsetup/commit/03a74b74e544df44f0005d4a5b5b0b99931143ab

- https://gitlab.com/cryptsetup/cryptsetup/commit/48e93621861049f589e890c299f440c416eacf4f

(another note). Also backport this one:

- https://gitlab.com/cryptsetup/cryptsetup/commit/d2f0773eb8482f754d9a7599d26697efcdd25cd6

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2297