When trying to create LUKS1 volume on disks with 4K sectors, Fedora 38 installer fails with: gi.overrides.BlockDev.CryptoError: Invalid extra arguments specified. Only `data_alignment`and `data_device` are valid for LUKS 1.


Reproducible: Always

Steps to Reproduce:
Boot a Kickstart with "--luks-version=luks1" partition created on a device with 4K sectors.

See attached repro.sh script. It creates a minimal netboot Kickstart image and starts a QEMU VM, where the issue is reproduced. You can confirm that the problem is specific to F38 and 4K sectors by tweaking $VER and $SECTOR_SIZE variables at the top. Note that the %post section of the script is completely optional - it only illustrates the end goal (single, encrypted / partition spanning entire drive), but the failure happens at earlier stage.

Actual Results:  
Installer fails with an exception (see "Additional information", "Steps to reproduce" and attached logs)

Expected Results:  
Installer succeeds and creates a LUKS1 volume


Context: I'm using full-disk encryption without separate /boot and, because of GRUB limitations, this needs LUKS1 for the / partition. See e.g. https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html and https://wiki.archlinux.org/title/dm-crypt/Encrypting_an_entire_system.

I use following entry in Kickstart:

  part / --fstype=ext4 --onpart=/dev/sda1 --encrypted --luks-version=luks1 --passphrase=some_temp_password

This worked for years, on various machines and across multiple Fedora versions, up to F37. When reinstalling to F38 recently, it failed on one machine, with:

  File "/usr/lib/python3.11/site-packages/blivet/formats/luks.py", line 325, in _create
    blockdev.crypto.luks_format(self.device,
  File "/usr/lib64/python3.11/site-packages/gi/overrides/BlockDev.py", line 1060, in wrapped
    raise transform[1](msg)
  gi.overrides.BlockDev.CryptoError: Invalid extra arguments specified. Only `data_alignment`and `data_device` are valid for LUKS 1.

I narrowed it down to this particular system having a root drive with 4K sectors (all others have 512B). This is probably related to https://fedoraproject.org/wiki/Changes/LUKSEncryptionSectorSize although for some reason it did not surface before Fedora 38.

Looking further at https://github.com/storaged-project/blivet/blob/3.7-release/blivet/formats/luks.py#L308-L332 what I *think* is happening is that, for a 4K drive, the additional 'extra' gets added in #L321 without checking for LUKS version. It is then passed to blockdev.crypto.luks_format(), which rejects it as it only accepts two whitelisted values for LUKS1.

I hacked around it by patching luks.py in the installer image, forcing 'extra=None' in that call. I guess the proper solution would be to have additional check that would add the sector-size-related 'extra' only for LUKS2 volumes.

See attached logs for more details. Note that these are logs from the originally failing machine, including tons of additional configs and constraints. Logs from repro.sh should be more clear.