Oops, I'm confusing this with another bug report where a NTFS partition was getting misidentified as LUKS.
In this case, I suspect what happen is the user got very unlucky. Mke2fs always zaps the first 8k, *except* on sparc platforms (where the default is to use an inline partition table) and if it detects a BSD boot label. So if the LUKS encrypted superblock has 4 bytes that match the two possible values of the BSD boot label, mke2fs will skip zero'ing the boot sector.
I could remove that check, but on platforms that are dual-booting with BSD, this could run into problems.
In any case, I still think that moving the LUKS check makes sense in this case, since there's no way to improve the probing function, given the LUKS format.
Oops, I'm confusing this with another bug report where a NTFS partition was getting misidentified as LUKS.
In this case, I suspect what happen is the user got very unlucky. Mke2fs always zaps the first 8k, *except* on sparc platforms (where the default is to use an inline partition table) and if it detects a BSD boot label. So if the LUKS encrypted superblock has 4 bytes that match the two possible values of the BSD boot label, mke2fs will skip zero'ing the boot sector.
I could remove that check, but on platforms that are dual-booting with BSD, this could run into problems.
In any case, I still think that moving the LUKS check makes sense in this case, since there's no way to improve the probing function, given the LUKS format.