Return to Question

EDIT 2: change of enclosure was the culprit

The comment of @frostschutz made me realize:

The question remains "how did this drive shrink in the first place". Did you change enclosures or controllers? Or enable raid mode in a controller bios or something?

I had the drive connected through SATA on an old laptop. Deleted the partitions, made the LUKS container, copied everything I needed and then took it out. I was trying to use it with a USB/SATA cable, and that was the source of the problem. I just installed it again on the old laptop and works with no problem.

Now I'll add a partition table and build the LUKS container from 0. My question now is, the partition table will avoid this issue or should I still be careful about the block size?

EDIT: loop device approach

following frostschutz answer:

# losetup --find --show --read-only --sector-size 4096 --sizelimit 500107857920 /dev/sda
/dev/loop0
# cryptsetup open --readonly /dev/loop9 crypttest
# cryptsetup status crypttest 
/dev/mapper/crypttest is active.
  type:    LUKS2
  cipher:  aes-xts-plain64
  keysize: 512 bits
  key location: keyring
  device:  /dev/loop0
  loop:    /dev/sda
  sector size:  4096
  offset:  32768 sectors
  size:    976740384 sectors
  mode:    readonly
# mount -t ext4 -r /dev/mapper/crypttest /mnt/mnt1
mount: /mnt/mnt1: wrong fs type, bad option, bad superblock on /dev/mapper/crypttest, missing codepage or helper program, or other error.
# demsg
EXT4-fs (dm-0): bad geometry: block count 122092550 exceeds size of device (122092549 blocks)

If I adjust size-limit in losetup it only affects the size of device instead of the block count (effectively making the difference bigger rather than fixing it).

In a desperate attempt I added offset to the loop device setup but the only thing that achieves is that cryptsetup is not able to read the LUKS header.

I tried cryptsetup with the --device-size option to 500107857920 bytes, the closest multiple of 4096b, but it gives me the same error.

I tried cryptsetup with the --device-size option to 500107857920 bytes, the closest multiple of 4096b, but it gives me the same error. Using (size - offset)/4096*4096= 500091080704 also returns the same error.