Se estiver em uso, você deve verificar se ele está montado, loop-device'd, ainda cryptsetup-opened, ativo no LVM, parte de um conjunto de RAID, etc. e, em seguida, parar todas essas coisas. Também encerre qualquer processo em execução que possa estar usando o dispositivo (particionadores, instaladores, ddrescue, badblocks, ...). A lista de possibilidades sobre o que poderia estar usando um dispositivo é quase infinita. lsof ou fuser são capazes de capturar alguns deles ...
# example only, none of these are accurate
umount /dev/sda2
losetup -D
vgchange -a n
cat /proc/mdstat | grep -C 2 sda2
mdadm --stop /dev/md??
...
Ou, se você quiser ignorar deliberadamente o problema, coloque explicitamente um dispositivo de loop na parte superior e, em seguida, formate o dispositivo de loop. Você deve reiniciar depois para ver se o que ainda estava usando o dispositivo, corromperia o seu cabeçalho LUKS por causa disso (se você não pode abri-lo após a reinicialização, foi o que aconteceu). Sem reiniciar, você poderá copiar dados felizmente no dispositivo, mas tudo acabou depois ...
# dangerous hack
cryptsetup luksFormat $(losetup --find --show /dev/sda2) -s 512 -h sha512 ...
reboot
Verifique também se você está realmente trabalhando com o dispositivo correto. Em seu post você de alguma forma mencionou tanto o sda1 quanto o sda2, então qual é?
Isso não faz parte do seu problema, mas o aes-xts-plain está obsoleto em favor de aes-xts-plain64 . É também a cifra padrão, então você não precisa especificá-la. (veja cryptsetup --help ou luksDump depois).